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Отзывы о ВТОРОМ ИЗДАНИИ КНИГИ 


“По мнению некоторых, в своей книге Энди и Дэйв поймали молнию в бу- 
тылку; вряд ли кому-нибудь удастся в ближайшее время написать книгу, спо- 
собную взбудоражить целую отрасль так же, как и эта. Впрочем, молния иногда 
поражает одно и то же место дважды, и эта книга служит явным тому доказа- 
тельством. Ее обновленное содержимое обеспечит ей неизменное присутствие в 
списке самых лучших книг по разработке программного обеспечения в течение 
последующих 20 лет, т.е. там, где ей и надлежит быть". 


ВМ (Вики) Брассер (УМ (УсКу) Втазеит), 
директор программы Ореп Ѕоитсе Ѕітаіеру 
(Стратегия открытого исходного кода) 

в компании Јипірет Међуоткѕ 


“Если вы стремитесь сделать свое программное обеспечение легко модерни- 
зируемым и сопровождаемым, держите под рукой эту книгу. В ней вы найдете 
немало практических советов как технического, так и профессионального ха- 
рактера, которые еще многие годы сослужат вам верную службу в ваших про- 
ектах”. 


Андреа Гуле (Апагеа Соиіеї), 
генеральный директор компании СотріБуіеѕ; 
учредитель компании ГевасуСоде.Коск$. 


“Это одна из тех книг, которые вывели меня из прежней колеи и направили 
на путь успешной профессиональной деятельности в области разработки про- 
граммного обеспечения. Читая ее, я открыл для себя возможности стать искус- 
ным мастером своего дела, а не просто шестеренкой в большом механизме. Это 
одна из самых знаменательных книг в моей жизни”. 


Оби Фернандес (ОШе Еетпапа??), 
автор книги Тһе Кай; Мау. 


“Для новых читателей эта книга может послужить увлекательным введением 
в мир современных практик разработки программного обеспечения, в станов- 
лении которого не последнюю роль сыграло первое издание книги. Те, кто уже 
читал первое издание книги, вновь откроют в ней поучительные выводы и муд- 
рые практические советы, которыми она отличается в первую очередь. Матери- 
ал настоящего издания тщательно отобран и обновлен”, 


Дэвид А. Блэк (рама А. Віаск), 
автор книги Тһе УеП-Стоипаеа КиђБуіѕі. 
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“Я бережно храню на своей книжной полке старый экземпляр первого изда- 
ния этой книги. Мне не раз приходилось перечитывать ее, чтобы изменить свое 
отношение к занятию программированием. В новом издании изменилось все и 
ничего: сейчас я читаю книгу на своем планшете іРай, разбирая примеры исход- 
ного кода на современных языках программирования, но при этом основопола- 
гающие принципы, понятия и подходы остаются по-прежнему актуальными и 
повсеместно применимыми. Спустя двадцать лет эта книга остается востребо- 
ванной, как никогда прежде. И мне радостно осознавать, что нынешние и буду- 
щие разработчики смогут многое почерпнуть из кладезя знаний Энди и Дэвида, 
как это некогда удалось и мне”. 


Сэнди Мамоли (5апау Матой), 
наставник по гибкой разработке программного обеспечения, 
автор книги Ном $е]--$@есНоп Ге Реоре Ехсё. 


“Первое издание этой книги, вышедшее двадцать лет назад, коренным обра- 
зом изменило направление моей профессиональной деятельности. Новое изда- 
ние может сделать то же самое и в вашей жизни”, 


Майк Кон (МіКе Соћп), 
автор книги Зиссееётя ий Азйе, АзИе Еѕіітаіпе 
апа Ріаппіпе, апа Оѕет Зюпез Аррііей. 


Посвящения 


Посвящается Джельет и Элли, Захари и Элизабет, Генри и Стюарту. 


ОБ АВТОРАХ 


Дэйв Томас и Энди Хант являются признанными на международном уровне 
ведущими авторитетами в сообществе разработчиков программного обеспече- 
ния. Они консультируют и выступают с докладами по всему миру. Совместно 
они основали издательство Ргартаќіс Воокз$Ве{, выпускающее завоевывающие 
награды передовые книги для разработчиков программного обеспечения и яв- 
ляются авторами Манифеста гибкой разработки (АріЇе Мапіќеѕќо). 

В настоящее время Дэйв преподает в колледже, увлекается резьбой по дереву 
и экспериментирует с новыми технологиями и парадигмами программирования. 
Энди пишет научно-фантастические повести, активно музицирует и любит по- 
возиться с техникой. Но больше всего оба они стремятся постоянно учиться. 


ргааддауе .ме 


ёоо1ѕћеа. сот 


ПРЕДИСЛОВИЕ 


Помню, как Дэйв и Энди впервые сообщили в Туееѓег о новом издании этой 
книги. И это было важное известие. Я наблюдал, с каким воодушевлением со- 
общество программистов встретило это известие, и оживленно откликнулся на 
него, предвидя, что двадцать лет спустя настоящее издание окажется столь же 
востребованным, как и прежде. 

И то, что книга с подобной историей получила такие отклики, говорит о мно- 
гом. Мне выпала честь прочитать рукопись этой книги, чтобы написать насто- 
ящее предисловие к ней, и тогда я понял, почему она вызвала такой переполох. 
И хотя это техническая литература, назвав ее таковой, можно сослужить ей 
плохую службу. Ведь техническая литература нередко отпугивает своим содер- 
жимым, изобилующим сложными описаниями, непонятными терминами, за- 
мысловатыми примерами, невольно вызывающими у читателя ощущение собс- 
твенной тупости. Чем опытнее автор книги, тем легче читателю забыть, что при 
изучении новых концепций он является начинающим. 

Несмотря на многолетний опыт программирования, Дэйву и Энди пришлось 
преодолеть немалые трудности, чтобы писать книгу с воодушевлением людей, 
только что освоивших уроки данной профессии. Они не обращаются с чита- 
телем свысока, не считают его знатоком и даже не предполагают, что он читал 
первое издание книги. Они воспринимают читателей такими, какими они есть 
на самом деле, — программистами, которые стремятся совершенствоваться. 
И чтобы помочь читателям в этом, они посвящают данной цели немало страниц 
своей книги, делая один практический шаг за другим. 

Откровенно говоря, они уже делали это и прежде. Ведь первое издание книги 
изобиловало реальными примерами, новыми идеями и практическими совета- 
ми, которые и ныне актуальны для приобретения навыков программирования 
и выработки умения мыслить как программист. И все же в настоящее обновлен- 
ное издание были внесены два важных усовершенствования. 

Первое усовершенствование вполне очевидно и состоит в исключении уста- 
ревших ссылок и примеров, которые были заменены новым, современным со- 
держимым. В настоящем издании вы не найдете примеры инвариантов циклов 
или сборочных машин. Не обращаясь к прежним примерам, Дэйв и Энди пос- 
тарались составить материал таким образом, чтобы читатели смогли извлечь из 
него наибольшую пользу, прорабатывая отдельные уроки. В настоящем издании 
такие старые принципы, как “не повторяться” (4оп\ гереаї уопгзе, ОКУ), очи- 
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щены он накопившейся пыли и отреставрированы, и сверкают новыми яркими 
красками. 

Но по-настоящему привлекательным настоящее издание делает именно вто- 
рое усовершенствование. После написания первого издания книги у ее авторов 
была возможность поразмыслить над тем, что они пытались в ней сказать, что 
ее читатели должны были вынести из нее и воспринять ее так, как хотелось бы 
авторам. Они получили отзывы на первое издание, выяснили, что было не так, 
что требовало уточнения, а что было неверно понято. За двадцать лет книга 
дошла до рук и сердец программистов во всем мире, а Дэйв и Энди, изучив от- 
зывы о ней, сформулировали новые принципы и понятия. 

Они усвоили важность поддержки и осознали, что поддержка, бесспорно, 
присуща разработчикам программного обеспечения в большей степени, чем 
представителям большинства других профессий. Поэтому они начали настоя- 
щее издание с простого, но мудрого посыла: “это ваша жизнь’. Он напоминает 
нам о нашем потенциале в развитии созданной нами кодовой базы, нашей ра- 
боте и карьере. Он задает тон всей остальной части книги, которая представля- 
ет собой нечто большее, чем очередная техническая литература, изобилующая 
примерами исходного кода. 

Эта книга выгодно отличается от многочисленной технической литературы 
на данную тему ясным пониманием ее авторов, что в действительности означает 
быть программистом. Программирование — это попытка облегчить будущее, а 
следовательно, труд коллег. Это умение быстро оправиться после совершенных 
оплошностей, воспитание хороших привычек и овладение арсеналом инстру- 
ментальных средств. Но само программирование является лишь частью мира 
программиста, который исследуется в этой книге. 

Мне пришлось потратить немало времени, размышляя о жизненном пути в 
программировании. Я не вырос на программировании, не изучал его в колледже 
и не увлекался в юности техникой. Я приобщился к области программирования 
к 25 годам, когда мне пришлось самому разбираться, что означает быть програм- 
мистом. Сообщество программистов заметно отличается от других сообществ, в 
которые мне довелось входить. В этом сообществе заметна особая преданность 
обучению и практичности, которая не только оживляет, но и отпугивает. 

Для меня вхождение в такое сообщество сродни открытию совершенно но- 
вого мира или, по крайней мере, нового города, где мне нужно познакомиться с 
соседями, выбрать свой продуктовый магазин, найти лучшую из кофеен. Потре- 
буется немало времени, чтобы сориентироваться на местности, найти наиболее 
эффективные маршруты, избегать улиц с интенсивным движением, знать, когда 
наиболее вероятны транспортные пробки. Погодные условия также могут быть 
иными, чем в старом месте жительства, а следовательно, придется сменить свой 
гардероб. 
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Первые несколько недель, а то и месяцев пребывания в новом городе мо- 
гут оказаться ужасными. И в этот период было бы замечательно иметь друже- 
любного знающего соседа, давно живущего в городе. Кто может провести для 
вас экскурсию по кофейням? Только тот, кто хорошо знает местную культуру, 
чувствует пульс жизни города и поможет вам не только почувствовать себя как 
дома, но и стать полезным членом сообщества. И такими соседями для вас, чи- 
татели, окажутся Дэйв и Энди. 

У относительно начинающего может легко вызвать потрясение не столько 
сам акт программирования, сколько процесс его становления как программиста. 
Ведь для этого потребуется определенный сдвиг в образе мышления, изменение 
привычек, видов поведения и ожиданий. Процесс вашего становления лучшим 
программистом не произойдет лишь потому, что вы знаете, как программиро- 
вать. Ему должно удовлетворять твердое намерение и тщательно продуманная 
практика. И эта книга служит руководством по эффективному становлению 
лучшим программистом. 

Но имейте в виду, что в книге ничего не говорится о том, как следует про- 
граммировать. Никаких философских рассуждений и обоснований по этому по- 
воду вы в ней не найдете. Авторы просто и ясно поясняют, как стать програм- 
мистом-прагматиком и выбрать свой подход к программированию, оставляя за 
читателями право самим решать, желают ли они стать именно такими програм- 
мистами. Если вы считаете, что быть программистом-прагматиком — не для 
вас, то авторы ничего против этого не будут иметь. Но если вы все же решите 
им стать, они станут вашими дружелюбными соседями, показывающими путь 
к желанной цели. 


Сарон Иитбарек (батоп ҮіагеК), 
учредитель и генеральный директор компании 
СойеМ№Меуђіе Ноѕі оў Соттапа пе Негоез. 
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В далекие 1990-е годы мы работали с компаниями, испытывающими затруд- 
нения в своих проектах. И оказалось, что мы каждый раз спрашивали у них 
одно и то же: “Может, вам лучше сначала тестировать свои программные про- 
дукты, а затем поставлять их? Почему код создается только на машинах разра- 
ботчиков и никто не спрашивает о нем мнения пользователей?” 

Чтобы сэкономить время новых клиентов, мы стали делать заметки, которые 
в конечном счете превратились в эту книгу. И к нашему удивлению, книга, по- 
видимому, нашла живой отклик у читателей, не потеряв свою популярность в 
течение прошедших двадцати лет. 

Но двадцать лет — немалый срок для разработки программного обеспечения. 
Если попытаться переместить разработчика во времени из 1999 года и ввести 
его в современную команду, он будет бороться с чуждым ему новым миром. Но 
ведь и мир 1990-х годов в равной степени чужд современному разработчику. 
Ссылки в настоящем издании на литературу по СОВВА, САЗЕ, индексирован- 
ным циклам были бы в лучшем случае забавны и, вероятнее всего, сбивали бы 
с толку. 

В то же время прошедшие двадцать лет не оказали никакого влияния на то, 
что называется общими принципами. Ведь могла измениться технология, но не 
люди. Некогда пригодные нормы практики и методы остаются таковыми и по- 
ныне. Эти вопросы, рассматривавшиеся ранее в книге, теперь вполне созрели. 

И когда настало время выпустить настоящее 20-летнее юбилейное издание, 
нам пришлось принять нелегкое решение. С одной стороны, мы могли бы про- 
смотреть и обновить описание тех технологий, на которые мы ссылались в пре- 
дыдущем издании, и на этом поставить точку. А с другой стороны, мы могли 
бы пересмотреть свои рекомендации по поводу тех норм практики, которые мы 
рекомендовали раньше, исходя из опыта, накопившегося за прошедшие двад- 
цать лет. Но в конечном счете мы сделали и то и другое. 

В итоге книга стала чем-то подобным кораблю Тесея'. Около одной трети тем 
в ней оказались совершенно новыми, а остальные были частично или полно- 
стью переписаны. Мы намеревались сделать изложение материала более понят- 
ным, уместным и, как можно надеяться, непреходящим. 


1 Е 2 
Известный философский парадокс: если с годами заменить каждую вышедшую из строя 
часть корабля, то останется ли он в итоге тем же самым кораблем? 
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Нам пришлось принять ряд трудных решений. В частности, мы опустили при- 
ложение “Первоисточники” как потому, что было бы невозможно сохранить его 
актуальность, так и потому, что нужные первоисточники читателю проще найти 
самостоятельно. Кроме того, мы реорганизовали и переписали темы, касающи- 
еся параллелизма, принимая во внимание современное изобилие аппаратного 
обеспечения для параллельных вычислений и недостаток способов их органи- 
зации. Наконец, мы добавили материал, отражающий перемены в отношениях и 
средах: от движения за гибкую разработку, началу которого мы способствовали, 
до растущего принятия идиом функционального программирования и потреб- 
ности принимать во внимание конфиденциальность и безопасность. 

Любопытно, однако, что споров по поводу содержимого настоящего издания 
у нас было меньше, чем при написании первого издания этой книги. Мы оба 
считали, что выявить важный материал на этот раз было проще. 

Так или иначе, настоящее издание увидело свет, так что пользуйтесь им во 
благо, возможно, приняв новые нормы практики, а может быть, решив, что 
некоторая часть предлагаемого нами материала вам не подходит. Но в любом 
случае мы надеемся, что вы глубже вникнете в свое ремесло и откликнетесь на 
нашу книгу. А самое главное, не забудьте позабавиться. 


(СТРУКТУРА КНИГИ 


Эта книга написана как собрание кратких тем, каждая из которых самодоста- 
точна и посвящена конкретному предмету. В тексте вы найдете многочислен- 
ные перекрестные ссылки, помогающие ввести каждую тему в соответствующий 
контекст. Отдельные темы можно читать в произвольном порядке, поскольку 
эта книга составлена таким образом, чтобы не читать ее от корки до корки. 

Периодически в книге вам будут встречаться врезки под заголовком “Совет 
пп” (например, “Совет 1. Заботьтесь о своем ремесле”). Мы рассматриваем по- 
добные советы как обращающие на себя внимание места в тексте книги. Они 
имеют самостоятельное значение и служат для того, чтобы пользоваться ими 
ежедневно в практической деятельности. 

В настоящем издании были включены упражнения и задачи там, где это было 
уместно. Как правило, упражнения имеют относительно простые решения, тог- 
Да как задачи допускают многие решения. Чтобы дать представление о ходе сво- 
их рассуждений, мы выделили решения упражнений в отдельное приложение к 
книге, хотя лишь немногие из них имеют единственное правильное решение. А 
предлагаемые задачи могут послужить основанием для групповых обсуждений 
или самостоятельных работ на специализированных курсах по программирова- 
нию. Кроме того, в конце книги приведен перечень литературы (книг и статей), 
на которую делаются явные ссылки в тексте самой книги. 
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Что ОЗНАЧАЕТ ИМЯ 


“— Когда я беру слово, оно означает то, 
что я хочу, не больше и не меньше, — 
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сказал Шалтай-Болтай презрительно”. 


Льюис Кэрролл, Алиса в Зазеркалье 


Текст книги испещрен различными профессиональными терминами: как 
обычными словами, несколько искаженными, чтобы выразить какой-то особый 
технический смысл, так и жуткими словами, намеренно выбранными для обоз- 
начения отдельных понятий из вычислительной техники теми специалистами 
в данной области, которые пренебрежительно относятся к языку. При первом 
употреблении термина делается попытка определить понятие, которое он обоз- 
начает, или хотя бы намекнуть на его смысловое значение. Но, на наш взгляд, 
одни термины так и остались невостребованными, тогда как другие (например, 
объект и реляционная база данных) — настолько распространены, что не требу- 
ют дополнительного определения. Если же вам встретится незнакомый прежде 
термин, не пропускайте его, а найдите время, чтобы выяснить его обозначение 
в Интернете или справочнике по вычислительной технике. И если ваши поиски 
завершатся удачно, то сообщите нам по электронной почте, чтобы мы добавили 
найденное вами определение термина в последующее издание книги. 

Несмотря на все сказанное выше, мы все же решили отомстить специалистам 
по вычислительной технике. В частности, мы решили пренебречь некоторыми 
вполне пригодными терминами для обозначения отдельных понятий. Почему? 
А потому, что существующая ныне терминология, как правило, ограничивает- 
ся конкретной предметной областью или стадией разработки. Но ведь один из 
основных принципов данной книги состоит в том, что большая часть рекомен- 
дуемых нами методик оказывается универсальной. Так, модульность применима 
к исходному коду, проектным решениям, документации и организации команд 
разработчиков. Когда же требовалось употребить обычный термин в более 
широком контексте, то возникало недоразумение, поскольку нам не удавалось 
преодолеть границы той смысловой нагрузки, которую нес первоначальный тер- 
мин. И когда происходило нечто подобное, мы решали пренебречь языковыми 
нормами, изобретая свои термины. 


с Перевод Н.М. Демуровой. 
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Исходный код И ДРУГИЕ РЕСУРСЫ 


Большая часть исходного кода, приведенного в этой книге, взята из компили- 
руемых исходных файлов и свободно доступна для загрузки с нашего веб-сай- 
та?. Там приведены также ссылки на другие полезные ресурсы наряду с обновле- 
ниями книги и новостями о других разработках программистов-прагматиков. 


ПРИСЫЛАЙТЕ НАМ СВОИ ОТЗЫВЫ 


Мы будем рады вашим откликам на книгу. Пишите нам по адресу электрон- 
ной почты ррЬоокК@ргааргоч. сом. 


БЛАГОДАРНОСТИ ЗА ВТОРОЕ ИЗДАНИЕ КНИГИ 


Мы выгодно воспользовались буквально тысячами интересных бесед о про- 
граммировании, проведенных за последние двадцать лет, встречая разных людей 
на конференциях, курсах, а иногда и просто в самолете. Каждая из таких бесед 
расширила наше представление о процессе разработки программного обеспече- 
ния и способствовала обновлению настоящего издания. Благодарим всех участ- 
ников этих бесед и просим известить нас, если мы в чем-то не правы. 

Благодарим также участников процесса создания бета-версии этой книги. 
Ваши вопросы и комментарии помогли нам лучше разъяснить отдельные воп- 
росы, затронутые в книге. 

Прежде чем перейти к бета-версии этой книги, мы поделились ее рукописью 
с несколькими людьми, чтобы они оставили свои комментарии к ней. Благо- 
дарим ВМ (Вики) Брассера (УМ (Уіску) Вгаѕѕеџг), Джеффа Лангра (Је Гапрт) 
и Кима Шриера (Кіт Ѕһгіег) за подробные комментарии, а Хозе Валима (Јоѕе 
Уаіт) и Ника Катберта (№ъ№іск Си Бен) — за техническое рецензирование. 

Благодарим Рона Джеффриса (Коп ЈеЌгіеѕ) за предоставленную нам возмож- 
ность воспользоваться примером из судоку. Выражаем большую признатель- 
ность сотрудникам издательства Реагѕоп, согласившихся на то, чтобы мы со- 
ставили эту книгу по-своему. Особая благодарность выражается незаменимой 
Джанет Ферлоу (]апеё Еџпом), которая мастерски справляется со всем, за что бы 
она ни бралась. В частности, она следила за тем, чтобы мы поэтапно выполняли 
свою работу над книгой в срок. 

Наконец, выражаем во всеуслышание слова искренней признательности всем 
программистам-прагматикам, сделавшим программирование лучше для всех за 
последние двадцать лет. Теперь остается еще двадцать лет. 


3 См. по адресу ВЕЕрз : / /ргадргод. сот/ё1ё1еѕ/6рр20/зѕоџгсе содае. 
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Эта книга поможет вам стать более совершенным программистом. Вы можете 
быть самостоятельным разработчиком, членом команды в крупном проекте или 
консультантом, одновременно работающим со многими компаниями. Так или ина- 
че, эта книга поможет вам в индивидуальном плане лучше выполнять свою работу. 
Она не носит теоретический характер, а сосредоточена на практических вопросах 
и применении накопленного опыта для принятия более обоснованных решений. 
Термин прагматик происходит от латинского слова ргартаіісиѕ, обозначающего 
“опытный в деле” и производного, в свою очередь, от греческого слова лраүратікёс̧, 
обозначающего “пригодный для использования”. Это книга о делании. 

Программирование — это ремесло. В простейшем случае оно сводится к тому, 
чтобы заставить компьютер сделать то, что требуется программисту или поль- 
зователю его программы. Программист выступает отчасти в роли слушателя, 
советчика, переводчика и диктатора. Он пытается уяснить туманные исходные 
требования и найти способ выразить их таким образом, чтобы вычислительная 
машина смогла воздать им должное. Он старается задокументировать и органи- 
зовать результаты своих трудов таким образом, чтобы другие могли их понять и 
опереться на них. Более того, программист старается сделать все это, несмотря 
на неумолимые сроки выполнения проекта. Каждый день программист творит 
небольшие чудеса, а это трудное дело. 

Многие люди готовы оказать помощь программисту. Так, поставщики инс- 
трументальных средств на все лады расхваливают чудеса, которые способны 
творить их программные продукты. Знатоки методологии обещают, что их ме- 
тодики гарантированно принесут ожидаемые результаты. И каждый заявляет, 
что его язык программирования самый лучший, а операционная система дает 
ответы на все мыслимые вопросы. 

Все это, конечно, не соответствует действительности, ведь простых ответов 
не бывает. Не существует самого лучшего решения, будь то инструментальное 
средство, язык программирования или операционная система. А могут быть 
лишь такие системы, которые более пригодны в конкретных обстоятельствах. 

Именно здесь и может пригодиться прагматизм, который означает, что не 
следует привязываться к какой-нибудь конкретной технологии, но нужно иметь 
достаточно обширные знания и опыт, позволяющие принимать правильные 
решения в конкретных обстоятельствах. Знания проистекают из понимания 
основных принципов вычислительной техники, а опыт — из обширного ряда 
практических проектов. Теория в сочетании с практикой составляют прочный 
фундамент для программиста. 
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Свой подход программист приспосабливает к текущим обстоятельствам и 
окружению. Он оценивает относительную важность всех факторов, оказываю- 
щих влияние на проект и пользуется своим опытом для выработки подходящих 
решений. И делает он это постоянно по мере продвижения своей работы. Про- 
граммисты-прагматики доводят свою работу до конца и делают ее хорошо. 


Кому АДРЕСОВАНА ЭТА КНИГА 


Она адресована тем, кто стремится стать более эффективным и продуктив- 
ным программистом. Вы, вероятно, испытываете разочарование от того, что 
не раскрываете, как вам кажется, свой истинный потенциал. А может быть, вы 
обращаете внимание на своих коллег, которые пользуются инструментальными 
средствами с целью повысить производительность своего труда. Возможно, в 
своей нынешней работе вы пользуетесь старыми технологиями и хотите узнать, 
как приложить новые идеи к тому, что вы делаете. 

Мы не претендуем ни на то, чтобы ответить на все (или хотя бы большинство) 
вопросы, возникающие у программистов, ни на применимость наших идей во всех 
возможных случаях. Мы можем лишь сказать, что если вы выберете наш подход, 
то быстро приобретете необходимый опыт, производительность вашего труда воз- 
растет и вы станете лучше понимать весь процесс разработки программного обес- 
печения. И в конечном счете вы сможете писать более качественные программы. 


Что ОЗНАЧАЕТ БЫТЬ ПРОГРАММИСТОМ-ПРАГМАТИКОМ 


Каждый разработчик неповторим, отличаясь своими сильными и слабыми 
сторонами, симпатиями и антипатиями. Со временем каждый разработчик со- 
здает свою собственную среду, отражающую его индивидуальность в той же не- 
умолимой степени, как и его увлечения, одежда или прическа. Но если вы явля- 
етесь программистом-прагматиком, то вам присущи многие из перечисленных 
ниже общих характеристик. 


® Своевременно принимаете новшества на вооружение и быстро приспо- 
сабливаетесь к ним. Инстинктивно чувствуете преимущества отдельных 
технологий и методик, и вам нравится опробовать их. Если вам дают что- 
то новое, вы быстро осваиваете его, присоединяя приобретенное к осталь- 
ным своим знаниям. Ваша уверенность рождается с опытом. 


® Любознательны. Стремитесь задавать вопросы. Например: как вы это 
сделали? Возникли ли у вас трудности с данной библиотекой? Что такое 
квантовые вычисления, о которых я слышал? Каким образом реализуются 
символические ссылки? Задавая подобные вопросы, вы как барахольщик 
собираете мелкие факты, каждый из которых может оказать влияние на 
какое-нибудь решение многие годы спустя. 
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® Мыслите критически. Редко принимаете что-то на веру, не получив сна- 
чала подтверждающие факты. Так, если коллеги говорят: “Потому что надо 
делать так!” или если поставщик обещает решить все ваши проблемы, вы 
нюхом чуете предстоящие трудности. 


® Реалистичны. Стараетесь понять потаенный характер каждого возника- 
ющего у вас затруднения. Подобный реализм дает вам ясное понимание, 
в чем именно состоят трудности и как долго их придется преодолевать. 
Глубоко понимая, что процесс должен быть трудным или его завершение 
отнимет время, вы приобретаете необходимую выдержку, чтобы спра- 
ВИТЬСЯ С НИМ. 


ә Мастер на все руки. Прилежно стараетесь освоить обширный ряд тех- 
нологий и сред, работая над тем, чтобы быть в курсе новых разработок. 
И хотя ваша текущая работа может потребовать специальной квалифи- 
кации, вы всегда готовы перейти в новые сферы деятельности и принять 
новые вызовы. 


Мы оставили рассмотрение большинства основных характеристик напосле- 
док. Они присущи всем программистам -прагматикам и настолько просты, что 
ИХ МОЖНО сформулировать в виде отдельных советов, как показано ниже. 


Заботьтесь о своем ремесле 


Мы считаем, что разрабатывать новое программное обеспечение нет смысла, 
если не позаботиться о том, чтобы делать это как следует. 


Думайте! О своей работе 


Чтобы стать программистом-прагматиком, мы призываем вас думать о том, 
что вы делаете в тот момент, когда вы это делаете. Это не единовременная ре- 
визия текущих норм практики, а непрерывная критическая оценка каждого 
принимаемого решения, производимая каждый день и в каждом проекте. Ни- 
когда не двигайтесь на автопилоте. Постоянно думайте, критически оценивая 
свою работу в реальном времени. Старый девиз корпорации ІВМ “ДУМАЙ!” 
(ТНІМК!) является мантрой для программиста-прагматика. 

Если такая работа покажется вам трудной, значит, вы выказываете реалис- 
тичную характеристику. На это потребуется немного вашего драгоценного вре- 
мени, которого, вероятно, и так не хватает. Но в награду за усердие вы более 
активно вовлекаетесь в свое любимое дело, чувствуя, что вполне владеете не- 
уклонно расширяющимся рядом предметов, а также получаете удовольствие от 
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постоянного совершенствования. А в долгосрочной перспективе потраченное 
вами время окупится сторицей, когда вы и ваша команда станете работать бо- 
лее эффективно, чтобы писать легко сопровождаемый код и проводить меньше 
времени на совещаниях. 


Индивиду‘ЛЬНЫЕ ПРАГМАТИКИ И КРУПНЫЕ КОМАНДЫ 


Некоторые считают, что индивидуальности нет места в крупных командах 
или сложных проектах. “Программное обеспечение — техническая дисцип- 
лина, — говорят они, — которая нарушается, если отдельные члены команды 
принимают решения самостоятельно”. Мы категорически не согласны с таким 
утверждением. 

В построении программного обеспечения должна присутствовать техничес- 
кая составляющая, но это совсем не мешает проявлять индивидуальное мас- 
терство. Рассмотрим в качестве примера крупные кафедральные соборы, пост- 
роенные в Европе в период Средневековья. Воздвижение каждого из них потре- 
бовало немалых затрат, измеряемых тысячами человеко-часов в течение многих 
десятилетий. Усвоенные уроки передавались от одного поколения строителей 
к другому поколению, которое совершенствовало строительную технику свои- 
ми индивидуальными достижениями. Но ведь плотники, каменотесы, резчики 
и стеклодувы были ремесленниками, воплощавшими технические требования 
в нечто целое, выходившее за пределы исключительно механической стороны 
строительства. Даже те, кто лишь тешут камни, должны всегда представлять 
себе целые соборы. 

Во всей структуре проекта всегда найдется место индивидуальности и мас- 
терству. И это особенно справедливо для текущего состояния разработки про- 
граммного обеспечения. Это состояние может показаться через сто лет таким 
же архаичным, как и методы, применявшиеся средневековыми строителями ка- 
федральных соборов, современным инженерам-строителям, хотя мастерство в 
данной отрасли по-прежнему в почете. 


Это НЕПРЕРЫВНЫЙ ПРОЦЕСС 


Турист, однажды посетивший Итонский колледж в Англии, спросил са- 
довника, как ему удается поддерживать лужайку в идеальном состоянии. 
“Очень просто, — ответил тот. — Нужно лишь смахивать росу каждое 
утро, стричь траву каждый день и сволакивать ее раз в неделю”. 


“И это все?” — спросил турист. 


“Абсолютно все! — ответил садовник. — Делайте это в течение 500 лет, 
и у вас тоже получится прекрасная лужайка”. 
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Прекрасные лужайки требуют небольшого ухода, как, впрочем, и отличные 
программисты. Консультанты по управленческим вопросам любят вставлять 
словечко кайзен в свои беседы. Термин кайзен по-японски обозначает понятие 
непрерывного процесса внесения многих мелких усовершенствований, что по- 
служило одной из главных причин для коренных изменений в производитель- 
ности и качестве изготовления японских товаров и широко размножившееся по 
всему миру. Кайзен применяется и на индивидуальном уровне, где отдельные 
личности ежедневно работают над совершенствованием собственных навыков, 
пополняя свой арсенал новыми инструментальными средствами. Но, в отличие 
от итонских лужаек, они начинают замечать результаты буквально через счи- 
танные дни. А с годами они изумляются, насколько расцвел их личный опыт, и 
развились их индивидуальные навыки. 


От ИЗДАТЕЛЬСТВА 


Вы, читатель этой книги, и есть главный ее критик и комментатор. Мы ценим 
ваше мнение и хотим знать, что было сделано нами правильно, что можно было 
сделать лучше и что еще вы хотели бы увидеть изданным нами. Нам интересно 
услышать и любые другие замечания, которые вам хотелось бы высказать в наш 
адрес. 

Мы ждем ваших комментариев и надеемся на них. Вы можете прислать нам 
электронное сообщение, либо просто посетить наш веб-сайт и оставить свои за- 
мечания там. Одним словом, любым удобным для вас способом дайте нам знать, 
нравится или нет вам эта книга, а также выскажите свое мнение о том, как сде- 
лать наши книги более интересными для вас. 

Посылая письмо или сообщение, не забудьте указать название книги и ее 
авторов, а также ваш обратный адрес. Мы внимательно ознакомимся с вашим 
мнением и обязательно учтем его при отборе и подготовке к изданию последу- 
ЮЩИХ КНИГ. 

Наши электронные адреса: 


Е-тай: іпЁоҝёаіа1іекііка. сом 
ММУ: Һр: //иии . діа1екііка. сот 


ГЛАВА 4 


Эта книга о вас. Будьте уверены, что программирование — это ваша карьера, 
а самое главное — это ваша жизнь, и она принадлежит вам. И вы приступили 
к чтению этой книги потому, что знаете, что можете не только сами стать более 
искусным разработчиком, но и помочь другим разработчикам стать лучше. Сле- 
довательно, вы способны стать программистом-прагматиком. 

Что же отличает программистов-прагматиков? На наш взгляд, это отноше- 
ние, стиль и философский подход к задачам и их решениям. Их мышление вы- 
ходит за пределы непосредственной задачи, ставя ее в более крупный контекст, 
чтобы получить общую картину. Ведь как иначе быть прагматичным без этого 
более крупного контекста и как в таком случае находить разумные компромис- 
сы и обоснованные решения? 

Еще один ключ к успеху состоит в том, что программисты-прагматики берут 
на себя ответственность за все, что делают, как обсуждается в разделе “Кот съел 
мой исходный код”. Будучи ответственными, программисты-прагматики не си- 
дят без дела, безучастно наблюдая за тем, как их проекты буквально распадают- 
ся на части из-за небрежения ими. Поэтому в разделе “Программная энтропия” 
далее в этой главе поясняется, как поддерживать свои проекты в безупречном 
состоянии. 

Большинство людей находят перемены трудными — иногда по веским осно- 
ваниям, а иногда просто по укоренившейся инерции. Поэтому в разделе “Суп из 
камней и вареные лягушки” рассматривается стратегия побуждающих к дейс- 
твию перемен и (ради равновесия) представлена поучительная история об од- 
ном земноводном, пренебрегшем опасностями, скрывающимися в постепенных 
переменах. 

Одно из преимуществ, дающих понимание контекста, в котором вы работа- 
ете, заключается в том, что вам просто легче выяснить, насколько качественно 
разработанное вами программное обеспечение. Иногда близкое к идеальному 
качество оказывается лишь одним из возможных вариантов, но зачастую при- 
ходится идти на компромиссы. Более подробно этот вопрос рассматривается в 
разделе “Подходящее программное обеспечение”. 
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Безусловно, чтобы все это осилить, потребуется обширная база знаний, по- 
этому обучение — это непрерывно продолжающийся процесс. В связи с этим в 
разделе “Ваш багаж знаний” описываются некоторые стратегии поддержания 
динамики данного процесса. 

Наконец, никто из нас не работает в вакууме. Все мы проводим немало вре- 
мени, общаясь с другими людьми. Поэтому в разделе “Общайтесь!” перечислены 
способы, помогающие делать это лучше. 

Прагматичное программирование происходит от философии прагматичного 
мышления. И в этой главе закладывается основание для такой философии. 


Это ВАША ЖИЗНЬ 


“Я в этом мире не для того, чтобы жить по вашим 
ожиданиям, а вы — не для того, чтобы жить по моим”. 
Брюс Ли“ 

Это ваша жизнь, и она принадлежит вам. Вы ее ведете и творите. 

Многие разработчики жалуются нам на свою разочарованность. Их пробле- 
мы различны. Одни ощущают застой в своей работе, а другие считают, что тех- 
нический прогресс обошел их стороной. Они полагают, что их недооценивают, 
им недоплачивают или в их командах отравляющая атмосфера. Возможно, они 
хотят переехать в Азию или в Европу, а может быть работать дома. И в ответ на 
все эти жалобы мы всегда задаем один и тот же вопрос: “Почему вы не можете 
это изменить?” 

Разработка программного обеспечения должна находиться близко к началу 
любого доступного списка требующихся специальностей. Навыки разработчи- 
ков востребованы, их знания распространяются за пределы географических гра- 
ниц, они работают в удаленном режиме, получая за свой труд хорошую плату. 
И вообще, они могут делать почти все, что хотят. 

Но по какой-то причине разработчики противятся переменам. Они выжида- 
ют, надеясь, что положение дел переменится к лучшему. Они пассивно наблюда- 
ют за тем, как их навыки устаревают, жалуясь на то, что их компании ничему их 
не обучают. Они рассматривают рекламные объявления экзотических стран в 
городском транспорте, а затем выходят под холодный дождь и бредут на работу. 
Поэтому ниже приведен самый важный совет в этой книге. 


У вас есть свобода выбора 


* Вгисе Іее — гонконгский и американский киноактер, режиссер, сценарист, продюсер, 
популяризатор и реформатор в области китайских боевых искусств. — Примеч. пер. 
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Вас заедает среда? Вам надоела работа? Попробуйте исправить положение, но 
не затягивайте свою попытку до бесконечности. По этому поводу Мартин Фау- 
лер говорит следующее: “Вы можете сменить организацию или изменить свою 
организацию””. 

Если вам кажется, что технический процесс обходит вас стороной, навер- 
стайте упущенное, изучая в свое личное время то, что вам кажется интересным. 
Тем самым вы инвестируете в самих себя — так что заниматься самообразова- 
нием в свободное от работы время вполне благоразумно. 

Желаете работать в удаленном режиме? Поинтересуйтесь в одном месте. Если 
вам откажут, поищите другое место, где вас возьмут на работу. Данная отрасль 
дает вам немало замечательных возможностей, поэтому проявите заранее ини- 
циативу, чтобы воспользоваться ими. 


Другие разделы, связанные с данной темой 
® Тема 4. Суп из камней и вареные лягушки. 


ө Тема 6. Ваш багаж знаний. 


А О О ЗА ТАРАГ ТАУ Е О ие АМ УИА П ТА О И Но КА сия 


Кот съЕЛ МОЙ ИСХОДНЫЙ КОД 


“Величайшей из всех слабостей есть страх 
показаться слабым”. 


Ж.Б. Боссюэ®, 
Политика из Святого Писания 
(РоПйнс; рот Нау Ити), 1709 г. 


Одним из краеугольных камней прагматичной философии является идея 
взять на себя ответственность за свои действия в отношении продвижения по 
карьерной лестнице, обучения и образования, выполнения своего проекта и 
повседневной работы. Программисты-прагматики сами заботятся о своей ка- 
рьере и не боятся признавать свое невежество или ошибки. Это, конечно, не 
самая приятная сторона программирования, но она все же проявляется даже в 
самых удачных проектах. Порой дело не ладится, несмотря на проведенное тес- 
тирование, грамотно составленную документацию и сплошную автоматизацию. 
И тогда выпуск программного продукта задерживается в связи с возникшими 
непредвиденными техническими трудностями. 

Если происходит нечто подобное, мы стараемся обращаться с командой как 
можно более профессионально. А это означает быть честными и откровенны- 


> См. по адресу ПЕЕр: / /мікі.с2.сот/ ?СпапдеҮоцгОгдапіғаііоп. 


6 Ј.В. Воѕѕце — французский проповедник и богослов ХУП века, а также писатель и епис- 
коп. — Примеч. пер. 
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ми. Мы можем гордиться своими способностями, но должны признавать и свои 
недостатки: невежество и ошибки. 


ДоверИЕ В КОМАНДЕ 


Прежде всего, ваша команда должна доверять вам и полагаться на вас, а 
вы — спокойно полагаться на каждого из ее членов. Доверие в команде совер- 
шенно необходимо для проявления творческой инициативы и сотрудничества, 
как следует из литературы, в которой исследуется данный вопрос’. В здоровом 
окружении, основанном на доверии, вы можете смело высказывать свои мысли, 
представлять свои идеи на суд коллег и полагаться на других членов команды 
так же, как и они на вас. Ведь без доверия... 

Представьте, что высокотехнологичная команда ниндзя незаметно проникает 
в самое логово преступников. После нескольких месяцев тщательного планиро- 
вания и изнуряющих тренировок вы, наконец-то, добрались до места. И теперь, 
когда настал ваш черед настроить систему лазерного наведения, вы неожиданно 
для остальных заявляете: “Извините, ребята, у меня нет с собой лазера. Мой кот 
играл с красной точкой лазерного целеуказателя, и поэтому я оставил его дома”. 
Нарушенное подобным образом доверие вряд ли удастся восстановить. 


ВЗЯТИЕ НА СЕБЯ ОТВЕТСТВЕННОСТИ 


Ответственность — это нечто такое, на что вы активно соглашаетесь. В част- 
ности, вы берете на себя обязательство обеспечить правильность выполнения 
какой-то работы, но совсем не обязательно имеете непосредственный контроль 
над каждой стадией данного процесса. Помимо того, что вы стараетесь выпол- 
нить свою работу как можно лучше, вам приходится также анализировать си- 
туацию на наличие неподконтрольных вам рисков. Вы имеете полное право не 
брать на себя ответственность за непредсказуемую ситуацию или такую, когда 
риски слишком велики или этические последствия слишком постыдны. И тогда 
вам придется принимать решение, исходя из ваших собственных ценностей и 
суждений. 

Если вы все же берете на себя ответственность за конечный результат, то 
должны учитывать, что вам придется нести ответственность за него. И если вы 
допустите оплошность, как это делаем все мы, или совершите ошибку в сужде- 
нии, то признайте ее честно и постарайтесь предложить другие варианты выхо- 
да из затруднительной ситуации. 

Не сваливайте вину на кого-то или что-то другое и не ищите оправданий. Не 
вините во всем трудности у поставщика, язык программирования, руководство 


4 Наглядный пример мета-анализа см. в статье Тгиѕі ап4 {еат регјоттапсе: А теїа-апауѕіѕ 
оў таіп еђесіѕ, тодетаіотѕ, апӣ соуатіаіеѕ (Доверие и производительность команды. Мета- 
анализ основных эффектов, посредников и ковариаций), доступной по адресу БЕЕрз : / / 
рзуспеѓ .ара.ога/аоііапаіпа?ӣо1=10.1037%2Еар10000110. 
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или коллег. Любой из этих факторов может сыграть свою отрицательную роль, 
но именно вы должны найти правильные решения, а не оправдания. 

На случай, если существует риск, что поставщик вас подведет, у вас должен 
быть план экстренных мероприятий. Если же выйдет из строя устройство памя- 
ти, а вместе с ним исчезнет весь исходный код и у вас не окажется его резервной 
копии, — это будет вашей оплошностью. Оправдание перед начальством вроде 
“кот съел мой исходный код” просто не пройдет. 


Предлагайте варианты разрешения затруднений, 
а не оправдания и извинения 


Прежде чем подходить к кому-нибудь и объяснять причины, по которым 
что-то нельзя сделать, что-то запаздывает или не работает, остановитесь и пос- 
лушайте себя. Обратитесь к резиновому утенку или котенку на своем мониторе, 
чтобы опробовать на нем, звучат ли ваши оправдания благоразумно или нелепо 
и как они будут звучать перед вашим начальством. 

Воспроизведите весь разговор в уме и подумайте, что, вероятнее всего, от- 
ветит другой его участник. Спросит ли он вас, пробовали ли вы сделать вот это 
или не учли ли вы вот то? Как вы на это ответите? Прежде чем идти к нему, 
чтобы сообщить плохие новости, подумайте, можно ли опробовать что-нибудь 
еще? Иногда вы просто знаете, что он вам ответит, так что избавьте его от лиш- 
них хлопот. 

Вместо оправданий предлагайте свои варианты разрешения затруднений. 
Не говорите, что чего-то нельзя сделать. Лучше поясните, что можно сделать, 
чтобы выйти из трудного положения. Некоторый исходный код должен быть 
удален? Скажите об этом и объясните важность этого рефакторинга (см. раздел 
“Тема 40. Рефакторинг” главы 7 “По ходу кодирования”). 

Требуется ли вам время на прототипирование, чтобы найти наилучший путь 
продолжить разработку (см. раздел “Тема 13. Прототипы и памятные записки” 
главы 2 “Прагматичный подход”)? Требуется ли вам внедрить более совершен- 
ное тестирование (см. разделы “Тема 41. Тестировать, чтобы кодировать” гла- 
вы 7 “По ходу кодирования” и “Строгое и непрерывное тестирование” главы 9 
“Прагматичные проекты”) или его автоматизация, чтобы не повторять тестиро- 
вание снова вручную? 

Вам могут понадобиться дополнительные ресурсы для окончательного реше- 
ния задачи тестирования, а возможно, придется уделить больше времени взаи- 
модействию с пользователями. Или же все дело просто в вас самих, а значит, вам 
требуется более углубленно изучить какую-нибудь методику или технологию. 
Помогут ли вам в этом какие-нибудь книги или курсы? Не бойтесь задаваться 
подобными вопросами или признаваться в том, что вам нужна помощь. 
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Старайтесь избавиться от слабых оправданий, прежде чем произносить их 
вслух. Если вы все же считаете, что должны оправдаться, сделайте это сначала 
перед своим котом. И если уж ваш Мурзик готов взять всю вину на себя, то... 


Другие разделы, связанные с данной темой 


® Тема 49. Прагматичные команды, глава 9 “Прагматичные проекты”. 


Задачи 


® Как вы отреагируете, если кто-нибудь (например, банковский служащий, 
автомеханик или чиновник) придет к вам со слабым оправданием? Какое 
у вас составится в итоге мнение о них и об их организации? 


® Если вы, так уж вышло, говорите: “Я не знаю”, непременно прибавьте: “Но 
я найду выход”. Это отличный способ признать, что вы чего-то не знаете, 
но все же берете на себя ответственность как профессионал. 


СИИ ЛАЛА ААА ИИС ЗАЛАМ А але ИМИТАТОР ОТО" СТАА ИФ. АЛО ет Теле ФСП Ва ИВА УАЛЬНИХ ПРА АИТ НОВА ЯЛТА НУ У ТЕЛА ОЕ КА ПХ АЛЕ ИЩИ В алия АЕ ра виа Мор Ни АТАЛА Уб 


ПРОГРАММНАЯ ЭНТРОПИЯ 


Несмотря на то что разработка программного обеспечения не подвержена 
большинству физических законов, все мы сильно подвержены воздействию 
неуклонного роста энтропии. Физический термин энтропия обозначает вели- 
чину беспорядка в системе. К сожалению, законы термодинамики утверждают, 
что энтропия во вселенной стремится к максимуму. Если же беспорядок воз- 
растает в программном обеспечении, то такое явление называется деградацией 
последнего. Некоторые могли бы назвать это явление более оптимистическим 
термином “технический долг’, подразумевающим, что когда-нибудь они погасят 
этот долг, — хотя этого, скорее всего, не произойдет. Но как бы ни называлось 
данное явление, техническим долгом или деградацией, оно может распростра- 
няться бесконтрольно. 

Имеется немало факторов, способствующих деградации программного обес- 
печения, и самый важный из них, по-видимому, имеет отношение к психоло- 
гии или культуре в работе над проектом. Психология может оказаться весьма 
тонким свойством вашего проекта, даже если вы работаете над ним самостоя- 
тельно. Какими бы совершенными ни были составленные планы или участники 
проекта, он все равно может быть подвергнут деградации и разрушению в те- 
чение всего срока своего действия. Тем не менее существуют и такие проекты, 
которые успешно противостоят естественной тенденции к беспорядку и ухит- 
ряются завершиться вполне удачно, несмотря на огромные трудности и посто- 
янные задержки и помехи. 
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В чем же тогда отличие? В старых кварталах городов одни здания красивы 
и чисты, тогда как другие выглядят как трухлявые развалины. Исследователи в 
сфере преступности и упадка городов открыли замечательный пусковой меха- 
низм, очень быстро превращающий чистое, нетронутое, нежилое здание в раз- 
рушенную и заброшенную трущобу?. Это разбитое окно. 

Оказывается, что если не отремонтировать хотя бы одно разбитое окно в 
течение какого-нибудь значительного периода времени, у жильцов возникнет 
ощущение заброшенности здания, а следовательно, отсутствия заботы городских 
властей о его состоянии. И, как следствие, разбивается еще одно окно, а люди 
начинают захламлять здание всяким мусором. На стенах такого здания появля- 
ются граффити и начинается серьезное разрушение его конструкции. В течение 
относительно короткого периода времени здание разрушается настолько, что 
у его владельца не возникает никакого желания отремонтировать его, и тогда 
ощущение заброшенности становится вполне реальным. 

Почему же возникает такое отличие? Как показывают исследования, прове- 
денные психологами”, безнадежность может оказаться заразной. Так, если рас- 
смотреть вирус гриппа в тесном помещении, то явное пренебрежение эпидеми- 
ческой ситуацией способно лишь утвердить в мысли, что ничего, вероятно, не- 
льзя исправить, никого это не волнует и все обречены на заболевание гриппом. 
Подобным же образом негативные мысли могут распространяться среди членов 
команды, образуя порочный круг. 


Нельзя жить с разбитыми окнами 


Совет “Нельзя жить с разбитыми окнами’, по существу, означает, что нельзя 
мириться с неудачными проектными решениями или плохо написанными фраг- 
ментами кода, оставляя их неисправленными. Исправляйте их, как только обна- 
ружите. Если же времени на исправление недостаточно, закомментируйте неис- 
правный код, выведите сообщение “Не реализовано” или же подставьте вместо 
него фиктивные данные подобно тому, как временно заколачивают разбитые 
окна. Словом, предпримите какое-то действие, чтобы предотвратить дальней- 
ший ущерб и тем самым показать, что вы владеете ситуацией. 

Нам приходилось видеть, как нормально функционирующие системы быс- 
тро приходят в негодность, как только начинают разбиваться окна. Имеются и 
другие факторы, способствующие деградации программного обеспечения, и мы 
еще коснемся их в дальнейшем, а до тех пор следует подчеркнуть, что пренебре- 
жение ускоряет деградацию быстрее, чем любой другой фактор. 


3 См. Тһе ройсе апа пеісћБотћоой ѕајеѓу [МН82]. 


? См. Соліасіоиѕ ертеѕѕіоп: Ежяепсе, зрес йсИу їо дертеѕѕей зутрюту, апӣ ће тоїе оўтеаѕѕигапсе 
ѕеекіпу [0194]. 
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Можно, конечно, возразить, что ни у кого нет времени на обследование про- 
екта и его полную очистку от разбитого стекла. В таком случае лучше заплани- 
ровать установку мусорного контейнера или переезд в соседнее здание. Но в 
любом случае не позволяйте энтропии одержать верх. 


ПРЕЖДЕ ВСЕГО — НЕ НАВРЕДИТЬ 


У Энди некогда был баснословно богатый знакомый. Его дом был в идеаль- 
ном порядке, обставленный дорогим антиквариатом, предметами искусства и т.д. 
Однажды гобелен, висевший слишком близко к камину, загорелся. Пожарные 
быстро прибыли на место, чтобы потушить пожар и спасти дом от разруши- 
тельного огня. Но прежде чем затащить свои длинные и грязные шланги в дом, 
они остановились, чтобы раскатать мат между входной дверью и очагом пожара, 
поскольку им не хотелось испортить ковер — в самый разгар пожара. 

Возможно, это и весьма крайний пример. Ведь первая обязанность пожар- 
ных — погасить огонь, пренебрегая сопутствующим ущербом. Но они трезво 
оценили ситуацию, будучи уверенными в своей способности справиться с ог- 
нем, и действовали аккуратно, чтобы не нанести имуществу лишний ущерб. 
Именно таким образом следует обращаться и с программным обеспечением, не 
нанося ему сопутствующий ущерб лишь потому, что оно находится в каком-то 
критическом состоянии. Ведь и одно разбитое окно — это уж слишком. 

Одного разбитого окна (т.е. плохо написанного фрагмента кода, неудачного 
управленческого решения, с которым команде приходится мириться в течение 
всего проекта) достаточно, чтобы все начало приходить в упадок. Если окажет- 
ся, что вы работаете над проектом с большим количеством разбитых окон, вам 
очень легко может прийти в голову следующая мысль: “Вся остальная часть это- 
го кода написана скверно, и я поступлю точно так же”. И совсем не важно, что 
до этого момента проект находился в отличном состоянии. В первоначальном 
эксперименте, на основании которого была выдвинута теория "разбитого окна”, 
заброшенный автомобиль стоял нетронутым целую неделю. Но однажды в нем 
было разбито одно окно, после чего автомобиль был обчищен и перевернут 
вверх дном в считанные часы. 

Подобным же образом, присоединившись к проекту, где код безупречен (т.е. 
написан ясно, изящно и грамотно), вам следует действовать крайне осторожно, 
чтобы не навредить, как пожарные в упомянутом выше примере. Даже если по- 
жар в самом разгаре (поджимают сроки, приближается дата выпуска, выставоч- 
ная демонстрация и т.д.), вы не должны стать первым, кто испортит все дело или 
нанесет дополнительный ущерб. Просто скажите себе: “Никаких разбитых окон”. 


Другие разделы, связанные с данной темой 
® Тема 10. Ортогональность, глава 2 “Прагматичный подход”. 
® Тема 40. Рефакторинг, глава 7 “По ходу кодирования”. 
е Тема 44. Именование, глава 7 “По ходу кодирования”. 
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Задачи 
® Помогите укреплению команды, обследовав окрестности проекта. Выбери- 
те два или три “разбитых окна” и обсудите со своими коллегами возник- 
шие трудности и возможные пути их разрешения. 


• Можете ли вы предсказать, когда разобьется первое окно? Какова будет 
ваша реакция? Если это стало следствием чужого решения или приказа 
начальства, то что вы можете с этим поделать? 


Ел РА ЖД оао АИА ААА ДИО АБ У А Кунт РИ ТРА АЕ ИМЕ 4а БЕН АЛИНЫ СААС ТӘ Петю ТЫ ат АТ АТА Зр Н ИА И АТ РАЯ Ее оС АЧИТ иене АУТ еле ВЕКУ МГЦ МИНИН ТИ ИРИНА. 


СУП ИЗ КАМНЕЙ И ВАРЕНЫЕ ЛЯГУШКИ 


Три солдата, возвращавшихся с войны домой, проголодались. Когда они 
увидели перед собой село, то воспряли духом, поскольку были уверены, 
что селяне накормят их. Но когда они добрались до села, то обнаружи- 
ли двери домов запертыми на замок, а окна закрытыми. После многих 
лет войны селянам не хватало еды, а ту, что у них была, они припря- 
тывали. 


Невзирая на постигшую их неудачу, солдаты вскипятили котелок воды, 
аккуратно положив в него три камня. Пораженные селяне вышли пос- 
мотреть на происходящее. 


“Это суп из камней”, — пояснили солдаты. — “И это все, что вы в него 
положили?” — спросили селяне. ‘Абсолютно все, хотя говорят, что он 
будет лучше на вкус, если положить в него немного моркови...” Один из 
селян удалился, тотчас вернувшись с корзиной моркови из своих при- 
прятанных запасов. 


Пару минут спустя селяне снова спросили: “Это все?”. “Пожалуй, — от- 
ветили солдаты, — пару картофелин придадут ему больше густоты”. 
И тогда удалился другой селянин. 


В течение последующего часа солдаты перечислили другие ингредиенты, 
которые могли бы сделать суп еще вкуснее: говядину, лук-порей, соль, 
зелень и специи. И всякий раз какой-нибудь другой селянин удалялся, 
чтобы принести что-нибудь из своих личных запасов. 


В итоге солдаты сварили большой котел горячего, дымящегося супа. 
Они извлекли из него камни и сели вокруг котла вместе со всем селом, 
чтобы впервые за многие месяцы насладиться сытным обедом, которо- 
го ни одному из них уже давно не доводилось отведывать. 


Из этой истории о супе из камней следуют два поучительных вывода. Солда- 
ты хитро воспользовались любопытством селян, чтобы заполучитьу них еду. Но 
еще важнее, что солдаты действовали подобно катализатору, объединив селян 
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вместе и тем самым показав им, что совместно они могут сотворить нечто та- 
кое, чего не удалось бы сделать каждому из них в отдельности. И это называется 
синергическим эффектом, когда в конечном счете выигрывают все. 

Время от времени и вам, может быть, придется подражать этим солдатам. 
Ведь вы можете оказаться в такой ситуации, когда точно знаете, что и как нуж- 
но делать. Перед вашим мысленным взором вся система, и вы знаете, что с ней 
все в порядке. Но стоит вам попросить разрешение взяться за доводку всего в 
целом, вы встретите препятствия и недоуменные взгляды. Люди сформируют 
комитеты, бюджеты потребуют утверждения, и все только усложнится. Каждый 
будет защищать свои ресурсы, что иногда называется “изначальной апатией’. 

И тогда наступает время выставить камни. Тщательно обдумайте, что имен- 
но вы можете обоснованно попросить. Разработайте и покажите это в готовом 
виде другим, чтобы изумить их. И тогда они скажут: “Конечно, было бы лучше, 
если бы мы это добавили...’ Притворитесь, что это неважно. Не вмешивайтесь 
до тех пор, пока они не начнут просить вас внедрить функциональное средство, 
которое вам первоначально требовалось. Ведь людям легче присоединиться к 
уже достигнутому успеху. Приоткройте им перспективы на будущее, и они спло- 
тятся вокруг вас °. 


Будьте катализатором перемен 


Со СТОРОНЫ СЕЛЯН 


С другой стороны, история о супе из камней повествует о едва заметном и 
постепенно употребляемом лукавстве, а также о чрезмерной сосредоточенности 
на чем-то одном. Ведь думая о камнях, селяне забывают обо всем остальном. Все 
мы попадаем в подобную западню едва ли не каждый день, когда что-нибудь 
незаметно подкрадывается к нам. 

Нам не раз приходилось наблюдать подобные симптомы, когда проекты мед- 
ленно, но верно выходили из подчинения. Большинство бедствий в програм- 
мном обеспечении начинается с едва заметных мелочей, и большинство проек- 
тов постепенно выходят за установленные пределы. Системы отклоняются от 
своих спецификаций одно функциональное средство за другим, тогда как одна 
“заплата” за другой вставляется во фрагмент кода до тех пор, пока в нем не 
останется ничего первоначального. Зачастую именно накапливающиеся посте- 
пенно мелочи портят нравы и разрушают команды. 


10 Делая это, вам, возможно, будет удобнее придерживаться линии поведения, припи- 
сываемой контр-адмиралу д-ру Грейс Хоппер (Сгасе Норрег), которая говорила: “Легче 
попросить прощения, чем получить разрешение.” 
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Не забывайте об общей картине 


Честно говоря, мы никогда не пробовали этого сами, но знатоки говорят, что 
если взять лягушку и опустить ее в кипящую воду, она тотчас выпрыгнет из 
нее наружу. Но если погрузить лягушку в кастрюлю с холодной водой, а затем 
постепенно нагреть ее, то лягушка не заметит постепенного повышения темпе- 
ратуры и сварится в кастрюле. 

Следует, однако, иметь в виду, что случай с лягушкой отличается от случая 
с разбитыми окнами, обсуждавшегося ранее в разделе “Тема 3. Программная 
энтропия”. Согласно теории разбитых окон люди теряют всякую охоту бороться 
с энтропией, поскольку воспринимают ее как безразличие всех остальных. А ля- 
гушка просто не замечает никаких изменений. 

Не уподобляйтесь пресловутой лягушке. Внимательно следите за общей кар- 
тиной происходящего. Постоянно присматривайте за тем, что происходит вок- 
руг вас, а не только за тем, что вы делаете сами. 


Другие разделы, связанные с данной темой 
® Тема 1. Это ваша жизнь. 


® Тема 38. Программирование по совпадению, глава 7 “По ходу кодирова- 


> 


НИЯ. 


Задачи 


® Рецензируя рукопись первого издания этой книги, Джон Лакос поднял сле- 
дующий вопрос: солдаты сознательно вводят все больше в заблуждение 
селян, хотя перемены, которые они ускоряют, идут всем только на пользу. 
Но если сознательно вводить все больше в заблуждение лягушку, то можно 
нанести ей вред. Можете ли вы определить, готовите ли вы суп из камней 
или лягушек, когда пытаетесь ускорить перемены? Является ли такое ре- 
шение субъективным или объективным? 


® Быстро ответьте, не глядя на потолок, сколько осветительных приборов 
висит над вами? Сколько выходов из помещения, где вы находитесь, и 
сколько в нем присутствует людей? Есть ли там что-нибудь чуждое или 
выглядящее неуместным? Это упражнение в осведомленности об окружа- 
ющей обстановке — метод, практикуемый в разных кругах: от бойскаутов 
до летчиков. Выработайте сначала в себе привычку смотреть и замечать 
все, что происходит вокруг вас, а затем перенесите ее на свой проект. 
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Достаточно ХОРОШЕЕ 
ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ 


<< 


ля лучшего добро сгубить легко”. 
У Шекспир, Король Лир, действие 1, сцена 4 


Есть старый анекдот об американской компании, заказавшей 100 тысяч мик- 
росхем у японского производителя. В спецификации на микросхемы было, в 
частности, указано, что брак должен составлять 1 штуку на 10 тысяч хороших 
микросхем. Заказ был доставлен через несколько недель и состоял из одной 
крупной коробки, содержавшей тысячи микросхем, и другой, мелкой, в которой 
было всего лишь десять микросхем. К этой коробке была приклеена этикетка, на 
которой было написано “Бракованные микросхемы”. 

Хорошо, если бы иу нас контроль качества был на таком же уровне. Но ре- 
альность не позволяет нам производить ничего совершенно идеального, и осо- 
бенно бездефектного программного обеспечения. Ведь время, технология и тем- 
перамент словно сговорились против этого. 

Но это и не повод для разочарования. Как описал Эд Юрдон в своей статье 
И’Йеп воо4-епоизй ѕоўиате 15 ђбеѕі (Когда достаточно хорошее программное обес- 
печение оказывается наилучшим) в журнале ІЕЕЕ Ѕоўњаге, [Үоџ95], можно при- 
учить себя писать достаточно хорошие программы, которые достаточно хороши 
для пользователей, будущих сопровождающих их программистов и для спокойс- 
твия вашего духа. В этом случае вы работаете более продуктивно, а пользовате- 
ли ваших программ удовлетворены в большей степени. А кроме того, вы можете 
обнаружить, что ваши программы только выигрывают от сокращения их инку- 
бационного периода. 

Прежде чем продолжить, необходимо пояснить, о чем, собственно, здесь 
идет речь. Слово “подходящий” совсем не подразумевает небрежно или плохо 
написанный код. Все системы должны удовлетворять требованиям пользова- 
телей, чтобы считаться удачно спроектированными, а также соответствовать 
основным нормам производительности, конфиденциальности и безопасности. 
Мы просто ратуем за то, чтобы дать пользователям возможность участвовать в 
процессе принятия решения о том, когда произведенный программный продукт 
следует считать достаточно хорошим для удовлетворения их потребностей. 
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Идите НА КОМПРОМИССЫ С ПОЛЬЗОВАТЕЛЯМИ 


Как правило, вы пишете программы для других людей. И даже иногда не за- 
бываете выяснить, что же им, собственно, требуется!. Но спрашиваете ли вы 
их вообще, насколько хорошее программное обеспечение они хотят получить? 
Иногда у них просто нет никакого выбора. Если вы разрабатываете кардиости- 
мулятор, автопилот или низкоуровневую библиотеку, предполагающую широ- 
кое распространение, требования будут более строгими, а возможности вашего 
выбора — ограниченными. 

Но если вы работаете над совершенно новым программным продуктом, то на 
вашу разработку накладываются самые разные ограничения. Так, специалистам 
по сбыту требуется сдержать свои обещания, конечные пользователи могут со- 
ставлять планы, исходя из сроков поставки, а ваша компания, как всегда, испы- 
тывает дефицит денежных средств. Поэтому было бы непрофессионально пре- 
небрегать требованиями всех этих пользователей, просто дополнив программу 
новыми функциональными возможностями или “отполировав” исходный код 
еще раз. Мы ни в коем случае не сеем панику. Ведь в равной степени непрофес- 
сионально обещать невозможные временные рамки выполнения работ и нару- 
шать элементарные правила проектирования, чтобы уложиться в крайний срок. 
Область действия и качество производимой вами системы должны обсуждаться 
как часть требований к ней. 


Включайте в требования к системе вопрос о ее качестве 


Нередки случаи, когда приходится идти на разные компромиссы. Как ни 
странно, но многие пользователи готовы применять не до конца доведенное 
программное обеспечение сейчас, чем ждать еще целый год, пока оно не будет 
доведено до состояния готовой к выпуску полноценной версии. Хотя на самом 
деле то, что может понадобиться через год, все равно окажется совершенно 
другим. И с этим согласятся отделения информационных технологий (ИТ) мно- 
гих компаний со скромными бюджетами. Хорошее программное обеспечение 
сегодня зачастую оказывается более предпочтительным, чем совершенное про- 
граммное обеспечение завтра. Если вы предоставляете что-нибудь пользовате- 
лям для экспериментирования как можно раньше, их отзывы могут привести к 
более совершенному окончательному решению (см. раздел “Тема 12. Трассиру- 
ющие пули” главы 2 “Прагматичный подход”). 


1 Это, конечно, шутка! 


42 Глава 1 = Философия прагматизма 


ЗНАЙТЕ МЕРУ 


В какой-то степени программирование подобно живописи. Вы начинаете с 
чистого холста и некоторых основных исходных материалов. Используя соче- 
тание науки, искусства и ремесла, вы решаете, что с ними делать. Сначала вы 
набрасываете общую форму, затем раскрашиваете исходное окружение и, нако- 
нец, заполняете детали. При этом вы постоянно отходите назад и критическим 
взглядом оцениваете то, что уже сделано. А время от времени вы отбрасываете 
холст и начинаете все с самого начала. Но художники скажут вам, что все тяжкие 
труды пойдут прахом, если не вовремя остановиться. Так, если накладывать один 
слой краски на другой, деталь на деталь, то в краске потеряется сама живопись. 

Старайтесь не испортить грамотно написанную программу чрезмерными 
украшательствами и усовершенствованиями. Просто имейте в виду, что она 
никогда не будет совершенной. (Подробнее об основных принципах написания 
кода и несовершенстве этого мира речь пойдет в разделе “Пока вы программи- 
руете” главы 7.) 


Другие разделы, связанные с данной темой 


ә Тема 45. Западня требований, глава 8 “До начала проекта” 


> 


® Тема 46. Решение неразрешимых головоломок, глава 8 “До начала проекта”. 


Задачи 


• Просмотрите инструментальные средства и операционные системы, кото- 
рыми регулярно пользуетесь. Сможете ли вы найти в них признаки того, 
что их производители и/или разработчики спокойно выпускают програм- 
мное обеспечение, заранее зная, что оно несовершенно? Как его пользова- 
тель вы, скорее всего: 


1) подождете до тех пор, пока не будут исправлены все программные 
ошибки; 


2) примите как должное некоторые программные ошибки, учитывая слож- 
ность программного обеспечения; 


3) или же выберете более простое программное обеспечение, но с мень- 
шими дефектами? 


• Рассмотрите влияние модульности на выпуск программного обеспечения. 
Потребуется ли больше или меньше времени, чтобы получить тесно свя- 
занный монолитный программный блок требуемого качества по сравне- 
нию с системой, состоящей из очень слабо связанных модулей или мик- 
рослужб? Каковы преимущества и недостатки каждого из этих методов 
проектирования? 
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е Можете ли вы сказать о распространенном программном обеспечении, 
что оно страдает от раздутости функциональных средств, т.е. содержит 
намного больше функциональных средств, чем вам вообще может потре- 
боваться? Ведь каждое функциональное средство может стать источником 
программных ошибок и брешей в защите. И чем больше таких средств, тем 
труднее их находить, когда потребуется ими воспользоваться. Чувствуете 
ли вы себя в опасности попасть в такую западню? 


Рат ЛМ ере И АО ВОВА У БО МДАА ЛН ут еН ТО РМА а ТА аралат О С САО ое Правое 


ВАШ БАГАЖ ЗНАНИЙ 


“Инвестиции в знания приносят наибольшие дивиденды”. 


Бенджамин Франклин 


Ох, уж этот старина Бенджамин Франклин — никогда не упустит случай про- 
изнести нравоучительную проповедь! Ну как же? Ведь если бы мы рано ложи- 
лись спать и рано вставали, то разве не стали бы отличными программистами: 
Ранней пташке — ранний корм... и что же тогда станет с ранним червячком? Но 
в данном случае Бенджамин попал не в бровь, а в глаз. Ведь ваши знания и опыт 
являются ныне самыми важными профессиональными ресурсами. 

К сожалению, эти ресурсы исчерпываются”. Ваши знания устаревают по 
мере разработки новых методик, языков и сред. Изменение в расстановке сил 
на рынке способно сделать ваш опыт устаревшим или неуместным. Принимая 
во внимание постоянно растущие темпы перемен в технологическом обществе, 
это может произойти довольно быстро. 

По мере убывания ваших знаний убывает и ваша ценность для вашей компа- 
нии или клиента. И нам хотелось бы воспрепятствовать такой тенденции, вооб- 
ще искоренив ее. Ваши способности учиться чему-то новому как раз и состав- 
ляют самый важный стратегический ресурс. Но как приобрести способность 
учиться чему-то новому и как знать, чему именно следует учиться? 


ВАШ БАГАЖ ЗНАНИЙ 


Мы предпочитаем рассматривать все, что программисты знают о вычисле- 
ниях, прикладных областях, в которых они работают, а также весь их опыт как 
багаж знаний, которыми они обладают. Управление багажом знаний очень похо- 
же на управление финансовым портфелем по описываемым ниже руководящим 
принципам. 


А Исчерпывающийся ресурс — это нечто такое, чья ценность убывает со временем. К харак- 
терным его примерам относится склад, заполненный бананами, а также билет на футбол. 
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1. Серьезные инвесторы по привычке регулярно вкладывают во что-нибудь 
свои денежные средства. 


2. Ключом к успеху в долгосрочной перспективе является диверсификация. 


3. Смышленые инвесторы составляют свои портфели, находя определенное 
равновесие между консервативными и высокодоходными, хотя и слишком 
рискованными инвестициями. 


4. Инвесторы пытаются приобретать ценные бумаги по малой цене, а про- 
давать их по высокой цене, чтобы получить наибольшую прибыль. 


5. Портфели должны периодически пересматриваться и заново уравновеши- 
ваться. 


Чтобы быть успешным в своей профессии, необходимо инвестировать в 
собственный багаж знаний, следуя таким же руководящим принципам, как и 
описанные выше для финансового портфеля. Правда, управление такого рода 
инвестициями — это такой же навык, как и любой другой, а следовательно, ему 
можно научиться. Самое главное — сначала заставить себя, а затем развить в 
себе привычку делать это. С этой целью выработайте соответствующую проце- 
дуру, чтобы следовать ей до тех пор, пока она не укоренится в вашем сознании. 
И тогда вы обнаружите, что впитываете новые знания автоматически. 


Создание СВОЕГО БАГАЖА ЗНАНИЙ 


® Инвестируйте регулярно. Подобно финансовому инвестированию, вы 
должны не менее регулярно инвестировать в багаж своих знаний, пусть 
даже и в небольших объемах. И здесь привычка важна в такой же степени, 
как и объемы инвестиций, поэтому зарезервируйте для этой цели время и 
место, чтобы не отвлекаться ни на что другое. Несколько примерных целей 
перечислены в следующем разделе. 


• Диверсифицируйте свои инвестиции. Чем более разнообразны ваши зна- 
ния, тем ценнее вы сами. Вы должны как минимум знать все особенности 
той технологии, которой пользуетесь в настоящий момент. Но не останав- 
ливайтесь на этом. Перемены в вычислительной технике происходят очень 
быстро, и если какая-нибудь технология весьма востребована сегодня, то 
завтра она окажется практически бесполезной или, по крайней мере, не- 
востребованной. Чем больше технологий вы освоите, тем легче вам будет 
приспосабливаться к переменам. И не забывайте все остальные навыки, 
которые могут вам потребоваться в любой момент, в том числе и навыки, 
приобретенные в нетехнических областях знаний. 
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• Управляйте риском. Технологии бывают самые разные: от рискованных, 
но и потенциально высокорентабельных и до малорискованных, но и ма- 
лорентабельных. Не стоит вкладывать все свои средства ни в высокорис- 
кованные акции, которые могут внезапно обесцениться, ни тратить их 
консервативно, упуская при этом неплохие возможности. Не кладите все 
яйца в одну корзину, полагаясь на какую-то одну технологию. 


ә Покупайте дешево, а продавайте дорого. Освоить появившуюся техноло- 
гию еще до того, как она найдет широкое распространение, пожалуй, так 
же трудно, как и найти акции, продающиеся по цене существенно ниже 
рыночной. Но затраченные усилия могут вполне окупиться сторицей. Так, 
изучать язык Јауа в то время, когда он только появился и был малоизвес- 
тен, было рискованно, но усилия тех, кто принял его сразу, окупились 
впоследствии сторицей, когда он стал мейнстримом в данной отрасли. 


• Пересматривайте и заново балансируйте багаж своих знаний. Информа- 
ционная отрасль развивается очень динамично. Новоиспеченная техноло- 
гия, в которую вы начали инвестировать в прошлом месяце, сегодня мо- 
жет оказаться окаменевшим ископаемым. Возможно, вам стоит освежить 
знания технологий баз данных, которыми вы уже давно не пользовались, а 
может быть, лучше подумать о новой работе и попытаться изучить другой 
ЯЗЫК... 


Самый первый из всех перечисленных выше руководящих принципов легче 
всего выполнить, поэтому он еще раз упоминается ниже. 


Регулярно инвестируйте в свой багаж знаний 


ЦЕЛИ 


Теперь, когда известны некоторые руководящие принципы управления бага- 
жом знаний, необходимо выяснить самый лучший путь для приобретения ин- 
теллектуального капитала, который можно инвестировать в этот багаж знаний. 
Ниже приведен ряд рекомендаций по этому поводу. 


е Каждый год изучайте хотя бы один новый язык. Разные языки позволя- 
ют по-разному решать одни и те же задачи. Изучив самые разные подходы 
к решению задачи, вы расширяете горизонты ее осмысления, избегая опас- 
ности застрять в тупике. Кроме того, изучение многих языков облегчается 
благодаря большому разнообразию свободно доступного программного 
обеспечения. 
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® Читайте по одной книге из технической литературы каждый месяц. Не- 


смотря на обилие кратких статей и порой надежных ответов в Интернете, 
для углубленного понимания предмета требуются книги с подробным его 
изложением. Просмотрите среди предложений в книготорговой сети ин- 
тересную литературу, связанную с вашим текущим проектом?. Как только 
чтение технической литературы войдет у вас в привычку, читайте ежеме- 
сячно по одной книге. Освоив технологии, которыми вы пользуетесь в на- 
стоящий момент, обратитесь к какой-нибудь другой технологии, не связан- 
ной с вашим текущим проектом. 


Читайте и нетехническую литературу. Очень важно не забывать, что ком- 
пьютерами пользуются люди, потребности которых вы стараетесь удовлет- 
ворить. Вы работаете с людьми, вам дают работу другие люди, а некото- 
рые люди даже пытаются незаконно проникнуть в вашу вычислительную 
систему. Поэтому не забывайте о человеческой стороне вашей профессии, 
которая требует совершенно иных навыков для межличностного общения 
(и хотя мы иронично называем их “легкими”, на самом деле приобрести 


их трудно). 


Посещайте курсы повышения квалификации. Поищите интересные кур- 
сы в местном колледже, университете или в Интернете, а возможно, и на 
очередной выставке или конференции. 


Участвуйте в местных пользовательских группах или собраниях. Изо- 
ляция может оказаться убийственной для вашей карьеры, поэтому поз- 
накомьтесь с людьми, работающими за пределами вашей организации. 
Старайтесь принимать активное участие во встречах по интересам, а не 
только приходить и слушать. 


Экспериментируйте с разными средами. Если раньше вы работали толь- 
ко с Міпдом, уделите время работе с Гапих. Если вы пользовались только 
сборочными файлами и текстовым редактором, опробуйте логически раз- 
витую интегрированную среду разработки с современными функциональ- 
ными средствами, и наоборот. 


Оставайтесь в курсе дела. Читайте новости и публикации в Интернете о 
технологиях, отличающихся от тех, которыми вы пользуетесь в своем теку- 
щем проекте. Это отличный способ выяснить, каким опытом их примене- 
ния обладают другие люди, ознакомиться с применяемой ими конкретной 
терминологией и т.д. 


? Возможно, мы субъективны, но отличную подборку литературы можно найти по адресу 


ВЕЕрз://ргааргочд. сом. 
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Очень важно не прерывать инвестирование в багаж своих знаний. Как толь- 
ко вы освоите какой-нибудь новый язык или технологическое новшество, пере- 
ходите к следующему, чтобы изучить его. 

Совершенно не важно, пользуетесь ли вы любой из освоенных вами тех- 
нологий в своем проекте или просто указываете их при составлении резюме. 
В процессе обучения вы расширяете горизонты своего мышления, открываете 
новые возможности и способы сделать что-нибудь конкретное. При обучении 
большое значение имеет взаимное обогащение идеями. Старайтесь применить 
усвоенные уроки в своем текущем проекте. И даже если конкретная технология 
в вашем проекте не применима, то вы все равно можете позаимствовать из нее 
какие-нибудь идеи. Так, если вы овладеете принципами объектно-ориентиро- 
ванного программирования, то сможете писать процедурные программы уже 
иначе. А уяснив парадигму функционального программирования, сможете ина- 
че написать объектно-ориентированный код и т.д. 


Возможности для ОБУЧЕНИЯ 


Итак, вы взахлеб читаете книги, держитесь в курсе самых передовых разра- 
боток в вашей области, что совсем не так легко. Когда же кто-то обращается к 
вам с вопросом и вы не имеете ни малейшего представления, что ему ответить, 
то открыто признаетесь в этом. Но это не должно вас останавливать. Примите 
это как личный вызов и найдите ответ. Поспрашивайте у других, поищите ответ 
в Интернете, причем не только в бытовых, но и в академических кругах. 

Если вы не можете найти ответ сами, найдите того, кто способен это сделать. 
Не оставляйте заданный вам вопрос без ответа. Общение с другими людьми по- 
может вам создать свой личный круг знакомств, где в ходе расспросов вы можете 
неожиданно для себя найти ответы и на другие, не связанные с данным вопросы. 
И при этом багаж ваших прежних знаний станет пополнятся новыми... 

На все это чтение и изучение вам, конечно, требуется время, которого и так 
не хватает, поэтому подобные занятия необходимо планировать заранее. У вас 
всегда должно быть что-нибудь почитать в те моменты, когда вам нечего делать. 
Так, временем ожидания приема у доктора, в очереди или в городском транспор- 
те можно выгодно воспользоваться для чтения, поэтому берите всегда с собой 
электронную книгу. Хотя вы, может быть, предпочитаете по старой привычке 
мусолить пальцами печатные издания вроде зачитанной до дыр газеты 1973 года 
о положении в Папуа Новой Гвинее. 


КРИТИЧЕСКОЕ МЫШЛЕНИЕ 


Наконец, очень важно уметь критически осмысливать то, что вы читаете и 
слышите. Вам следует позаботиться о том, чтобы знания в вашем багаже были 
точными, непредубежденными и не поддающимися влиянию поставщиков или 
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шумихе, поднятой в средствах массовой информации. Берегитесь страстных 
приверженцев, настаивающих на том, что только их догма дает правильный от- 
вет — это может быть и неприемлемо для вас, и вашего проекта. 

Ни в коем случае не следует недооценивать силу коммерциализации. Если 
что-то оказывается в первых строчках результатов поиска в Интернете, то это 
совсем не означает, что оно самое лучшее. Ведь за то, чтобы занять ведущее 
положение в результатах поиска, могли просто заплатить. И если какая-нибудь 
книга выставлена на заметное место в книжной лавке, то это совсем не означает, 
что она хорошая или даже популярная. Ведь издательство могло заплатить за то, 
чтобы его книгу выставили на видном месте. 


Критически анализируйте то, что вы читаете и слышите 


Критическое мышление само по себе является отдельной дисциплиной, по- 
этому мы рекомендуем вам изучать ее и читать все, что только можно найти о 
ней. Между тем, вы можете начать с нескольких перечисленных ниже вопросов 
и обдумать их. 


• Пять вопросов “Почему?”. Задать хотя бы пять вопросов “Почему?” — из- 
любленный прием консультантов. Задайте сначала один такой вопрос и 
получите ответ. Затем копните глубже, задав еще один вопрос “Почему?”. 
Повторяйте эту процедуру словно нетерпеливый, но вежливый четырех- 
летний ребенок. Подобным образом вам, возможно, удастся приблизиться 
к коренной причине. 


® Кому это выгодно? Такой вопрос может показаться циничным, но следо- 
вание за деньгами — это очень полезный путь для анализа. Выгоды для 
кого-нибудь другого лица или другой организации могут совпадать или не 
совпадать с вашими личными выгодами. 


ә Каков контекст? Все происходит в своем контексте, именно поэтому уни- 
версальные решения годятся не на все случаи жизни. Так, если вы читаете 
статью или книгу, где пропагандируется ‘норма наилучшей практики’, вам 
уместно задаться следующими вопросами. Наилучшая практика для кого? 
Каковы предпосылки и последствия в краткосрочной и долгосрочной пер- 
спективе? 


• Когда и где это будет действовать? При каких обстоятельствах? Не слиш- 
ком ли поздно или же слишком рано? Не останавливайтесь на мышлении 
первого порядка: что произойдет дальше? Но перейдите далее к мышле- 
нию второго порядка: что произойдет после этого? 


• Почему это вызывает трудности? Есть ли какая-то базовая модель и как 
она действует: 
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К сожалению, на этом простые вопросы исчерпываются. Но, пополняя багаж 
своих знаний и применяя в какой-то степени критический анализ к целой лавине 
читаемых вами технических статей, вы сможете уяснить и сложные вопросы. 


Другие разделы, связанные с данной темой 
ә Тема 1. Это ваша жизнь. 


ә Тема 22. Технические дневники, глава 3 “Основные инструментальные 
средства”. 


Задачи 


® Начните на этой неделе изучение нового языка. Если вы привыкли про- 
граммировать на одном и том же старом языке, опробуйте СіІојиге, Ейхит, 
Е], Е#, Со, НазКе|, Руфоп, К, КеазопМГ, Кобу, Киз, ЅсаЈа, Зуи, Турезсире 
или любой другой язык, который может привлечь ваше внимание или 
просто понравиться вам“. 


е Начните читать новую книгу (как только дочитаете эту!). Если вы зани- 
маетесь подробной реализацией и кодированием, прочитайте книгу по 
проектированию и архитектуре программного обеспечения. А если вы 
занимаетесь высокоуровневым или архитектурным проектированием, то 
прочитайте книгу по технологиям кодирования. 


® Обсудите какую-нибудь технологию с людьми, не занятыми в вашем теку- 
щем проекте или работающими в других организациях. Познакомьтесь с 
такими людьми в кафетерии вашей организации или на местном собрании 
приверженцев данной технологии. 


РН (УАЗ А АА саналуу 79 АМАА НИ ЗЕ о ее ХАЙ коня ие. Ор жи лит СЯ ЗАТ ИЛЬ АЛЬ САС ХХ иа аа МАРТ М ЗДАНИЙ адаа уела Яо ма к них РГ етисе ема мат ля ИЕН Др, УКВ ИА И ВУ 


ОБЩАЙТЕСЬ! 


“Я считаю, что лучше быть проигнорированной вовсе, 


ы 22 


чем недооцененной”. 
Мэй Уэст,? фильм “Красавица 90-х” (ВеЙе оў іће №тенез), 1934 г. 


* Если вы никогда не слышали ни одном из этих языков, вспомните, что знание — ис- 
черпывающийся ресурс, и то же самое можно сказать о распространенной технологии. 
Перечень новейших и экспериментальных языков сильно изменился после первого изда- 
ния данной книги, а возможно, он уже будет иным к тому времени, когда вы будете читать 
эти строки. И это служит еще одним веским основанием для того, чтобы не переставать 
учиться. 


> Мае Үеѕі — актриса, драматург, сценарист и секс-символ первой половины ХХ века в 
Америке — Примеч. пер. 
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Вполне возможно, что мы в состоянии усвоить урок, преподанный мисс Уэст. 
Ведь дело не только в том, что у вас есть, а в том, как вы это преподнесете. Имея 
самые лучшие идеи, самый изящный код или самое прагматичное мышление, 
вы в конечном счете окажетесь в полной изоляции, если на сумете общаться с 
другими людьми. Хорошая идея без эффективного общения осиротеет. 

Как разработчики, мы должны общаться на самых разных уровнях. Мы про- 
водим немало часов на совещаниях, слушая и говоря, общаемся с конечными 
пользователями, пытаясь уяснить их потребности, пишем код, передающий 
наши намерения вычислительной машине и документирующий наше мышле- 
ние для будущих поколений разработчиков, а также пишем предложения и па- 
мятные записки, требующие и обосновывающие ресурсы, составляем отчеты 
о текущем состоянии дел и предлагаем новые подходы. Наконец, мы работаем 
каждый день в своих командах, проповедуя собственные идеи, видоизменяя су- 
ществующие нормы практики и предлагая новые. Большую часть своего рабоче- 
го дня мы проводим в общении, а следовательно, нам нужно делать это умело. 

Рассматривайте свой родной язык как очередной язык программирования. 
Пишите на естественном языке так, как вы пишете код, учитывая принципы 
ОКУ и ЕТС, рассматриваемые в следующей главе, возможности автоматизации 
и пр. 


Родной язык — это просто еще один язык программирования 


В последующих разделах перечислены дополнительные идеи по поводу обще- 
ния, которые, на наш взгляд, кажутся полезными. 


ЗНАЙТЕ, С КЕМ ВЫ ОБЩАЕТЕСЬ 


Общение полноценно лишь в том случае, если вы передаете собеседнику то, 
что подразумеваете, а для этого недостаточно просто говорить. Для этого не- 
обходимо знать потребности, интересы и способности тех, с кем вы общаетесь. 
Всем нам не раз приходилось присутствовать на совещаниях, где некоторые 
разработчики с остекленевшим взглядом слушали длинный монолог вице-пре- 
зидента по сбыту о преимуществах какой-нибудь мудреной технологии. Это не 
общение, а просто говорильня, навевающая скуку. 

Допустим, вам требуется внести изменения в свою систему дистанционного 
текущего контроля, чтобы воспользоваться сторонним брокером сообщений для 
распространения уведомлений о состоянии данной системы. С этой целью вы 
можете представить данное обновление системы самыми разными способами в 
зависимости от того, с кем именно вы общаетесь. Так, конечные пользователи 
по достоинству оценят такое обновление, поскольку их системы теперь смогут 
взаимодействовать с другими службами, пользующимися предлагаемым броке- 
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ром сообщений. Отдел сбыта вашей организации сможет воспользоваться этим 
фактом, чтобы увеличить объемы продаж, а руководители отделов разработки 
и эксплуатации просто обрадуются, поскольку заботы по сопровождению этой 
части системы лягут на чужие плечи. Наконец, разработчикам будет, возможно, 
интересно приобрести опыт работы с новыми прикладными интерфейсами и 
даже попробовать найти брокеру сообщений новые области применения. Сде- 
лав соответствующий краткий доклад для каждой из этих групп в отдельности, 
вы сможете заинтересовать их всех своим проектом. 

Как и во всех остальных формах общения, самое главное здесь — обратная 
связь. Следует не просто ждать вопросов, а попросить их задавать. Обращайте 
внимание на движения тел и выражения лиц тех, кто вас слушает. Одна из ис- 
ходных предпосылок в нейролингвистическом программировании гласит: зна- 
чение вашего общения состоит в реакции, которую вы получаете. Постоянно 
совершенствуйте свои знания тех, с кем общаетесь. 


ЗНАЙТЕ, ЧТО ВАМ ТРЕБУЕТСЯ СКАЗАТЬ 


Едва ли не самой трудной частью более формальных стилей общения, приме- 
няемых в деловой сфере, является умение подобрать именно те слова, которые 
требуется сказать. Писатели нередко составляют планы своих книг, прежде чем 
приступить к их написанию, а составители технической документации просто 
садятся за клавиатуру, набирают, например, приведенный ниже заголовок, а за- 
тем все, что следует после него. 


1. Введение 


Планируйте то, что хотите сказать. Сделайте сначала набросок своей речи, а 
затем спросите себя: “Передает ли эта речь тем, кто меня слушает, то, что я хочу 
выразить, именно так, как им было бы полезно?” Уточняйте свою речь до тех 
пор, пока не достигнете желанной цели. 

Такой подход пригоден не только для составления речей и документов. Когда 
вы встречаетесь с главным заказчиком на важном совещании или дискуссии, 
набросайте те идеи, которые хотите донести до него, и запланируйте пару стра- 
тегий ясного их изложения. Теперь, когда вы знаете, что именно вам требуется 
сообщить слушателям, останется лишь правильно подать все это. 


ВЫБИРАЙТЕ УДОБНЫЙ МОМЕНТ 


Представьте, что сейчас конец рабочего дня в пятницу недели, когда про- 
ходила аудиторская проверка. Младший ребенок вашей начальницы попал 
в больницу, на дворе льет дождь как из ведра, а дорога за город домой сулит 
превратиться в сущий кошмар. Это, вероятно, не самый подходящий момент 
попросить у начальницы разрешение увеличить оперативную память на вашем 
компьютере. 
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Чтобы понять, что именно готовы услышать те, с кем вы общаетесь, необ- 
ходимо, в частности, выяснить их приоритеты. Поймайте своего руководителя 
сразу после нелегкого разговора с высшим начальством по поводу утери неко- 
торой части исходного кода, и вы не найдете более восприимчивого слушателя к 
вашим идеям относительно хранилищ исходного кода. Старайтесь высказывать 
свои идеи в подходящий момент, облекая их в удобную для восприятия форму. 
Иногда для этого достаточно спросить: “Удобно ли сейчас поговорить о...?” 


ВЫБИРАЙТЕ СТИЛЬ ОБЩЕНИЯ 


Подбирайте стиль донесения своих мыслей под тех, кому вы их адресуете. 
Одним требуется формальное краткое сообщение “самих только фактов”, а дру- 
гим — длинная, обширная дискуссия, прежде чем перейти к делу. Поэтому необ- 
ходимо знать уровень их квалификации и опыта в данной области, т.е. являются 
ли они знатоками или новичками. Требуется ли им подробная сопроводитель- 
ная записка или же краткое изложение самой сути в сообщении по электронной 
почте? Если сомневаетесь, спрашивайте. 

Но не забывайте, что вы — лишь половина двухстороннего общения. Если 
кто-нибудь скажет вам, что ему требуется лишь абзац с кратким описанием ва- 
шего предложения, а вы не видите способа изложить его короче, чем на несколь- 
ких страницах, скажите об этом откровенно. Не забывайте о том, что ответная 
реакция, какой бы она ни была, также является формой общения. 


ПодАВАЙТЕ СВОИ ИДЕИ В ПРИВЛЕКАТЕЛЬНОЙ ФОРМЕ 


Ваши идеи, безусловно, важны и поэтому заслуживают того, чтобы сообщить 
их в привлекательной форме. Составляя письменные документы, слишком мно- 
гие разработчики (или их руководители) сосредоточивают основное внимание 
только на их содержании. Мы считаем это ошибкой. Любой повар (или менед- 
жер сети ресторанов) скажет вам, что вы можете часами работать как каторж- 
ный на кухне лишь для того, чтобы кто-то испортил все ваши труды плохой 
подачей блюда. 

Ныне оформлению малопривлекательных документов нет оправдания — 
современное программное обеспечение способно на поразительные результаты 
подготовки документов, будь они созданы с использованием языка разметки 
или в текстовом редакторе. Для этого достаточно выучить всего лишь несколь- 
ко команд. Так, если вы пользуетесь текстовым редактором, подберите подходя- 
щие таблицы стилей и шаблоны. (Вполне возможно, что они уже определены в 
вашей организации, а следовательно, вы можете воспользоваться уже готовыми 
шаблонами.) Научитесь оформлять верхние и нижние колонтитулы страниц. 
Чтобы получить представление о стилях оформления и компоновке докумен- 
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тов, обратитесь к образцам, входящим в состав пакета текстового редактора. 
Выполните проверку орфографии сначала автоматически, а затем вручную. Ведь 
в тексте могут быть ошибки, которые не удастся уловить средству проверки — 
человеку свойственно ошиваться. :) 


ПРИВЛЕКАЙТЕ ТЕХ, С КЕМ ОБЩАЕТЕСЬ 


Нередко оказывается, что составляемые вами документы в конечном счете 
оказываются менее важными, чем сам процесс их подготовки. Поэтому при- 
влекайте по возможности тех, кому эти документы адресованы, уже на ранних 
стадиях их составления в черновом варианте. Получите их отзывы и восполь- 
зуйтесь их советами. Таким образом вы наладите хорошие рабочие отношения 
и при этом сможете улучшить свой документ. 


Учитесь СЛУШАТЬ 


Если хотите, чтобы вас услышали другие, научитесь слушать их. Даже в том 
случае, если вы полностью информированы, и даже тогда, когда стоите на фор- 
мальном совещании перед двадцатью руководителями, они не услышат вас, если 
вы не слышите их. 

Пригласите людей к дискуссии, задавая вопросы, или же попросите их сфор- 
мулировать обсуждаемую тему своими словами. Превратите совещание в диа- 
лог, и тогда вы сможете донести свою точку зрения более четко и эффективно. 
Кто знает, может быть, вы чему-то в итоге научитесь. 


ОТВЕЧАЙТЕ ЛЮДЯМ 


Если вы задаете кому-нибудь вопрос и человек вам не отвечает — вам ка- 
жется, что он невежлив. Но как часто вы сами не отвечали людям, когда они 
присылали вам сообщение по электронной почте или памятную записку, прося 
сообщить какую-нибудь информацию или предпринять некоторое действие: 
В суматохе повседневной жизни очень легко об этом забыть. Поэтому старай- 
тесь всегда отвечать на сообщения по электронной почте, даже если это будет 
простая фраза: “Я отвечу вам позже”. Если держать людей в курсе, они будут го- 
товы простить вам случайные оплошности, чувствуя, что вы о них не забыли. 


Важно не только то, что вы говорите, но и как вы это говорите 


Вы должны непременно общаться, если только не работаете в полной изоля- 
ции. Чем эффективнее будет ваше общение, тем больше станет ваше влияние. 
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ДокумЕНТАЦИЯ 


Наконец, осталось рассмотреть вопрос об общении через документацию. Как 
правило, разработчики мало задумываются о документации. В лучшем случае 
они считают ее досадной необходимостью, а в худшем — низкоприоритетной 
задачей, надеясь, что начальство забудет о ней под конец проекта. 

Программисты-прагматики воспринимают документацию как неотъемлемую 
часть общего процесса разработки. Составление документации можно упрос- 
тить, не дублируя усилия, не тратя зря время и держа документацию под рукой 
и, в частности, непосредственно в исходном коде. На самом деле к документа- 
ции можно применить все те же прагматические принципы, что и к исходному 


коду. 
Создавая документацию, не фиксируйте ее навечно 


Качественную документацию можно получить из комментариев в исходном 
коде, и поэтому модули и экспортируемые функции рекомендуется снабжать 
комментариями, чтобы облегчить участь других разработчиков, когда им при- 
дется пользоваться этими программными компонентами. Но это совсем не оз- 
начает, что мы согласны с теми, кто говорит, что каждую функцию, структуру 
данных, объявление типа данных и т.д. следует непременно снабдить коммента- 
риями. Такой механичный подход к составлению комментариев на самом деле 
усложняет сопровождение кода, поскольку при внесении изменений обновлять 
приходится не только исходный код, но и документацию. В связи с этим ре- 
комендуется ограничить комментирование исходного кода, не относящегося к 
прикладному интерфейсу АРІ, указанием причин, назначения и целей написа- 
ния кода. Ведь сам исходный код уже ясно показывает, как он написан, а сле- 
довательно, комментировать его излишне, поскольку это нарушает принцип 
“не повторяться” (ОКУ). 

Комментирование исходного кода дает идеальную возможность задокумен- 
тировать те трудноуловимые особенности проекта, которые нельзя задокумен- 
тировать где-нибудь еще: инженерные компромиссы, причины принятия конк- 
ретных решений и отвержения альтернативных решений и т.д. 


КРАТКИЕ ИТОГИ 


• Знайте, что вам требуется сказать. 
® Знайте, с кем вы общаетесь. 


® Выбирайте удобный момент. 


Тема 7 > Общайтесь! 55 


Выбирайте стиль общения. 

Подавайте свои идеи в привлекательной форме. 
Привлекайте тех, с кем общаетесь. 

Учитесь слушать. 

Отвечайте людям. 


Храните исходный код и документацию вместе. 


Другие разделы, связанные с данной темой 


Тема 15. Оценивание, глава 2 “Прагматичный подход”. 


Тема 18. Эффективное редактирование, глава 3 “Основные инструмен- 
тальные средства”. 


Тема 45. Западня требований, глава 8 “До начала проекта”. 


Тема 49. Прагматичные команды, глава 9 “Прагматичные проекты”. 


Задачи 


Имеется несколько хороших книг, в которых описывается общение в ко- 
мандах разработчиков, в том числе следующие: 


— Тһе Муса Мап-Мопий: Еѕѕауѕ оп Зойи’ате Епятеетия [Вго96]. 
— Реоріемате: Ртойисііуе Ртојесіѕ апа Театѕ [213]. 


Постарайтесь прочитать эти книги в ближайшие 18 месяцев. Кроме того, 
обратите внимание на книгу Ріпоѕаиг Втаіпѕ: Реаііпе иіїћ АП Тһоѕе ІтроѕѕіЫе 
РеорІе аі Мотк [ВК89], в которой обсуждается эмоциональный багаж, с ко- 
торым все мы приходим в новую рабочую среду. 


Когда будете в следующий раз делать презентацию или писать памятную 
записку, чтобы донести свою точку зрения, постарайтесь проработать со- 
веты из этого раздела, прежде чем приступить к делу. Ясно определите 
круг тех лиц, с которыми вам предстоит общаться. Пообщайтесь с ними, 
если это возможно, впоследствии, чтобы выяснить, насколько точно вы 
оценили их потребности. 
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Все, чтоупоминалосьвышеоб общении в письменной форме, в равной степени 
применимоикобщению по электронной почте, всоциальныхсетях, блогах ит.д. 
В частности, возможности электронной почты развились до такой степени, 
что она стала оплотом корпоративной связи, применяется для обсуждения 
контрактов, организации диспутов и даже служит в качестве свидетельств 
в суде. Но по какой-то причине люди, никогда не посылавшие ни жалкого 
листка документации по обычной почте, с удовольствием рассылают элект- 
ронной почтой скверного вида неуместные сообщения по всему миру. 


Наши рекомендации по общению в оперативном режиме довольно просты 
и перечислены ниже. 


® Тщательно выверяйте написанное, прежде чем щелкнуть на кнопке 
ОТПРАВИТЬ. 


® Выполняйте орфографическую проверку, чтобы обнаружить оплошности 
автоматической корректуры. 


® Придерживайтесь простого и понятного формата. 


® Старайтесь как можно меньше цитировать исходное сообщение при от- 
вете. Никому не нравится получать обратно свое сообщение по электрон- 
ной почте с присоединенным к нему единственным словом “Согласен”. 


® Если цитируете чужое сообщение в электронной почте, укажите его ав- 
тора и процитируйте его в теле своего сообщения, а не в виде вложения. 
Это же относится и к общению в социальных сетях. 


® Избегайте перепалок или троллинга, если не хотите преследований, ко- 
торые непременно последуют за таким поведением. Если не решаетесь 
высказать кому-нибудь в лицо все, что о нем думаете, — не делайте этого 
ив сети. 


® Проверяйте список получателей ваших сообщений, прежде чем отравлять 
их. Уже стало едва ли не нормой критиковать начальство по электронной 
почте, не замечая, что оно присутствует в качестве получателя сообщения 
в списке рассылки. А еще лучше — отказаться от критики начальства по 
электронной почте. 


Как считает бесчисленное множество организаций и политиков, электрон- 
ная почта и социальные сети — это уже навсегда. Поэтому постарайтесь 
уделить электронной почте столько же внимания, сколько и любой другой 
памятной записке или отчету. 


ГЛАВА 2 


_ __ ПРАГМАТИЧНЫЙ ПОДХОД 


Имеются определенные рекомендации и приемы, применяемые на всех уров- 
нях разработки программного обеспечения, совершенно универсальные процес- 
сы и почти аксиоматические идеи. Но такие подходы редко документируются, 
а вместо этого они зачастую обнаруживаются в виде отрывочных записей дис- 
куссий о проектировании, управлении проектом или программировании. Но 
ради вашего удобства мы постараемся здесь собрать все эти идеи и процессы 
вместе. 

Первая и, может быть, самая важная тема касается самой сути разработки 
программного обеспечения и раскрывается в разделе “Сущность качественного 
проектирования”. Из нее следует все остальное. Далее следуют разделы “ОКУ — 
пороки дублирования” и “Ортогональность’, в которых раскрываются две тесно 
связанные темы. В первом из них содержится предупреждение не дублировать 
знания по системам, а во втором — не разделять никакие фрагменты знаний по 
многим компонентам системы. 

По мере увеличения темпов изменений становится все труднее и труднее со- 
хранять приложения в должном состояния. Поэтому в разделе “Обратимость” 
мы рассмотрим некоторые методики, помогающие ограждать проекты от их из- 
меняющейся среды. 

Два последующих раздела также взаимосвязаны. Так, в разделе “Трассиру- 
ющие пули” речь пойдет о стиле разработки, позволяющем одновременно со- 
бирать требования, проверять проектные решения и реализовывать код. И это 
единственный способ идти в ногу с современной жизнью. А в разделе “Прото- 
типы и памятные записки” будет показано, каким образом прототипирование 
применяется для проверки архитектур, алгоритмов, интерфейсов и идей. В сов- 
ременном мире крайне важно проверять идеи и получать ответную реакцию, 
прежде чем безоговорочно принимать их. 

По мере созревания вычислительной техники разработчики во все большем 
количестве создают языки высокого уровня. И хотя еще не изобретен компиля- 
тор, способный принимать команду “сделай это вот так”, в разделе “Предметно- 
ориентированные языки” представлены более скромные рекомендации, которые 
вы можете реализовать самостоятельно. 
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Наконец, все мы работаем в условиях ограниченного времени и ресурсов. 
Нехватку таких ресурсов можно перенести легче (и принести большее удовлет- 
ворение начальству или клиентам), если постараться выяснить, как долго они 
будут затребованы. Именно об этом и пойдет речь в разделе “Оценивание”. 

Упомянутые выше принципы следует непременно иметь в виду во время раз- 
работки, чтобы писать более совершенный, быстродействующий и устойчивый 
код. Вы можете даже сделать его более удобочитаемым. 


Пе тяни я мови омлет Даа МТ ИНГЕ ЗЛАЯ рен ее ЛАЯ реа лире ЛИ АМА орет Да 2. 7. РА РИ део ее Зита р д ГА ли Ама дА ОНИ О И Салам оду АД МУМ ААМИИН Па АТТАС а МЛ даш еж 


СУЩНОСТЬ КАЧЕСТВЕННОГО ПРОЕКТИРОВАНИЯ 


В мире полно умников и знатоков проектирования программного обеспече- 
ния, жаждущих передать свою мудрость, приобретенную тяжкими трудами. Для 
этого существуют особые сокращения, списки (почему-то обычно из пяти пунк- 
тов), шаблоны, диаграммы, видеоматериалы, беседы, а возможно, и увлекатель- 
ные сериалы (Интернет есть Интернет), поясняющие закон Деметры с помощью 
интерпретирующего танца. 

И мы, авторы этой книги, грешим этим. Но нам хотелось бы внести поправ- 
ки в пояснение того, что лишь стало для нас очевидным. Прежде всего сделаем 
заявление общего характера. 


Удачное проектное решение легче изменить, чем неудачное 


Вещь считается удачно спроектированной, если она приспосабливается к 
тем, кто ею пользуется. Для кода это означает, что он должен приспосабливать- 
ся к изменениям. Поэтому мы верим в принцип легкости изменения (Еаѕіег іо 
Сһапре — ЕТС). Вот и все. 

Насколько мы можем судить, всякий принцип проектирования является 
частным случаем принципа ЕТС. Чем, например, хорошо уменьшение степени 
связывания? Оно хорошо тем, что разделяет обязанности, чтобы их легче было 
изменить. А это и есть принцип ЕТС. В чем польза принципа единственной 
ответственности? Она состоит в том, что изменения в требованиях зеркально 
отображаются в изменениях лишь в одном модуле. И это соответствует принци- 
пу ЕТС. Почему так важно именование? А потому, что удачные имена делают 
исходный код более удобочитаемым, а ведь его приходится читать, чтобы вне- 
сти в него изменения. И в этом случае соблюдается принцип ЕТС! 


Принцип ЕТС — это ЦЕННОСТЬ, А НЕ ПРАВИЛО 


Ценности — это сущности, помогающие принять решение сделать то или 
другое. Что касается осмысления программного обеспечения, то ЕТС является 
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руководящим принципом, помогающим выбрать правильный путь. Как и все 
остальные ценности, этот принцип должен плавно следовать за здравой мыс- 
лью, мягко подталкивая в правильном направлении. 

Но как этого добиться? Как показывает наш опыт, для этого требуется пер- 
воначальное сознательное подкрепление. Вам, возможно, придется потратить 
около недели, сознательно задавая себе вопрос: “Облегчило или же затруднило 
изменение всей системы в целом то, что я только что сделал?” Делайте это, когда 
сохраняете файл, пишете тест или исправляете ошибку в программе. 

В принципе ЕТС присутствует неявное предположение. Он предполагает, что 
человек способен выбрать из многих путей именно тот, который будет легче 
сменить впоследствии. Зачастую здравый смысл позволяет выбрать правиль- 
ный путь и дает возможность сделать обоснованное предположение. Но иногда 
на это нет и намека. Что ж, бывает и так. Мы считаем, что в подобных случаях 
можно сделать две вещи. 

Во-первых, если вы не знаете, какую конечную форму примут вносимые вами 
изменения, то всегда можете вернуться к пути “легкости изменений”: попытать- 
ся сделать заменяемым фрагмент кода, который вы пишете. В таком случае, что 
бы ни произошло впоследствии, этот фрагмент кода не станет неодолимой пре- 
градой на вашем пути. Такая мера кажется крайней, но на самом деле вы долж- 
ны так или иначе прибегать к ней постоянно. Это всего лишь забота о сохране- 
нии кода не связанным и согласованным. 

Во-вторых, рассматривайте это как способ развития инстинктов. Запишите 
данную ситуацию в своем журнале технического учета, упомянув выбранные 
вами варианты и некоторые предположения об изменениях. Оставьте метку в 
исходном коде. В дальнейшем, когда этот фрагмент кода придется изменить, вы 
сможете оглянуться назад и предоставить отчет самому себе. Это может помочь, 
когда вы в очередной раз окажетесь на аналогичной развилке. 

В остальных разделах этой главы рассматриваются конкретные идеи по по- 
воду проектирования. Но все они вызваны описанным здесь одним и тем же 
принципом легкости изменения. 


Другие разделы, связанные с данной темой 
е Тема 9. ОКУ — пороки дублирования. 
® Тема 10. Ортогональность. 
® Тема 11. Обратимость. 
® Тема 14. Предметно-ориентированные языки. 
о Тема 28. Развязывание, глава 5 “Гибкость или ломкость”. 


® Тема 30. Преобразовательное программирование, глава 5 “Гибкость или 
ломкость’. 


е Тема 31. Налог на наследование, глава 5 “Гибкость или ломкость”. 
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Задачи 


• Обдумайте принцип проектирования, которым пользуетесь регулярно. На- 
правлен ли он на то, чтобы сделать что-то легко изменяемым? 


® Подумайте также о языках и парадигмах программирования: объектно- 
ориентированного, функционального и т.п. Какие главные положительные, 
отрицательные или те и другие стороны они имеют для написания кода в 
соответствии с принципом ЕТС? 


е Что вы можете сделать при программировании для того, чтобы исключить 
отрицательные и выделить положительные стороны’? 


• Во многих текстовых редакторах имеется (встроенная или через расшире- 
ния) поддержка команд, выполняемых при сохранении файла. Настраи- 
вайте текстовый редактор на вывод сообщения "ЕТС?" всякий раз”, когда 
сохраняете изменения в файле. Пользуйтесь такой возможностью в качес- 
тве напоминания о необходимости обдумать написанный вами код. На- 
сколько легко его изменить? 


ОКУ — пороки ДУБЛИРОВАНИЯ 


Капитан Джеймс Тиберий Кирк’ предпочитал снабжать компьютер двумя 
противоречащими друг другу фрагментами знаний, чтобы нейтрализовать враж- 
дебный искусственный интеллект. К сожалению, тот же самый принцип может 
очень легко погубить ваш код. 

Программисты обычно собирают, организуют, хранят и используют знания. 
Они документируют знания в спецификациях, возрождают их в выполняемом 
коде и пользуются ими для проверок во время тестирования. К сожалению, зна- 
ния непостоянны. Они изменяются, и зачастую очень быстро. Так, ваше пред- 
ставление о каком-нибудь требовании может измениться после совещания с 
клиентом. Стоит правительству изменить какой-нибудь нормативный акт, и со- 
ответствующая бизнес-логика устаревает. Тесты могут показать, что выбранный 
алгоритм неработоспособен. Все это непостоянство означает, что нам приходит- 
ся большую часть времени работать в режиме сопровождения, реорганизации и 
преобразования знаний в своих системах. 


Перефразируя старую песню Ассепѓиаѓе Тйе Роянуе (Делайте акцент на положительном) 
Джонни Мерсера (Јоһппу Мегсег) — американского исполнителя, популярного в 1940-х 
годах. 


2 Или хотя бы каждый десятый раз, чтобы оставаться в здравом уме... 


3 Персонаж научно-фантастического телевизионного сериала Звёздный путь: Оригиналь- 
ный сериал (З{аг ТгеК: Тһе Огіріпа! Ѕегіеѕ). — Примеч. пер. 
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Многие полагают, что сопровождение приложения начинается после его выпуска 
и означает устранение программных ошибок и совершенствование функциональ- 
ных средств. Мы считаем, что они не правы. Программисты постоянно работают 
в режиме сопровождения, поскольку их представления изменяются день за днем, 
когда поступают новые требования, а уже имеющиеся требования развиваются 
по мере сосредоточения усилий на проекте. Может измениться и сама среда. Но, 
независимо от конкретной причины, сопровождение является не каким-то отде- 
льным видом деятельности, а обыкновенной стадией всего процесса разработки. 

Когда выполняется сопровождение, приходится искать и изменять представ- 
ления вещей, т.е. те крупицы знаний, которые вложены в приложение. Но дело в 
том, что знания очень легко продублировать в спецификациях, процессах и раз- 
рабатываемых программах. И делая это, разработчики навлекают сущий кошмар 
сопровождения, который начинается еще до выпуска приложения. Мы считаем, 
что единственный способ надежно разрабатывать программное обеспечение 
и упростить понимание и сопровождение разработок — следовать принципу 
“не повторяться” (ОКУ): 


У каждого фрагмента знаний должно быть единственное, недвусмыс- 
ленное, непререкаемое представление в системе. 


А почему этот принцип называется ОКУ? А вот почему: 


ОКУ — Ооп“ Кереаї Үоигѕеії, т.е. “не повторяйся” 


Альтернатива состоит в присутствии чего-то одного в двух или более местах. 
Если в таком случае изменить что-то одно, то нужно не забыть изменить и все 
остальное, а иначе программа будет загнана противоречием в угол, как компью- 
теры пришельцев. И вопрос не в том, чтобы вспомнить об изменениях, а в том, 
когда они забудутся. 

Принцип РКУ будет еще не раз упоминаться на страницах этой книги, и за- 
частую в таком контексте, который не имеет ничего общего с программирова- 
нием. Мы считаем, что это одно из самых важных инструментальных средств 
в арсенале программиста-прагматика. И в этом разделе мы вкратце изложим 
трудности, возникающие в связи с дублированием, а также предложим общие 
стратегии их преодоления. 


Принцип ОВУ НЕ ТОЛЬКО ДЛЯ КОДИРОВАНИЯ 


Прежде всего устраним некоторое недоразумение. В первом издании этой 
книги мы поступили неверно, объяснив лишь, что мы подразумевали под выра- 
жением “не повторяться”. И многие посчитали, что принцип ОКУ имеет отноше- 
ние только к коду, думая, что он означает “не выполнять копирование и вставку 
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строк исходного кода”. Но это лишь часть принципа ОКУ, причем мелкая и са- 
мая простая. Принцип ОВУ имеет отношение к дублированию знаний, а также 
намерений, т.е. к выражению одного и того же в двух разных местах, кроме того, 
возможно, разными способами. 

В качестве пробного камня попробуйте ответить на следующие вопросы: если 
должно быть изменено какое-нибудь свойство кода, то не придется ли вносить 
изменения во многих местах и в самых разных форматах? Не придется ли из- 
менять исходный код и документацию, схему базы данных и хранящуюся в ней 
структуру и т.д. Если это именно так, то такой код не соответствует принципу 
ОКУ. Рассмотрим некоторые типичные примеры дублирования. 


ДУБЛИРОВАНИЕ В ИСХОДНОМ КОДЕ 


Каким бы банальным это ни показалось, но дублирование кода — довольно 
частое явление. Ниже приведен характерный тому пример. 


ЧеЁ ргіпі ра1апсе (ассочпї) 
ргіпёҒ ""”рерієѕ: %10.2Е\п", ассоцпіё.аеріїёѕ 
ргіпіЁ "Сгеа1єѕ: %10.2#\п", ассоцпі.сгеаіізѕ 
1Е ассоипі.Ғееѕ < 0 
ргіпёҒ "Еееѕ: %10.2Е-\п", -ассоцпі.Ғееѕ 


е1зе 

рг1пеЕ "Еееѕ: %10.2Е\п", ассочцпе. Ееез 
епа 
РИА Е е ===" 


1Е ассооџпі.ра1апсе < 0 
ргіпіЁ "Ва1апсе: %10.2Е-\п", -ассоцпі.ра1апсе 
е1зе 
ргіпі# "Ва1апсе: %10.2Е\п", ассооцпё.ра1апсе 
епа 
епа 


Пренебрежем пока что следствиями типичной для новичков ошибки, работая 
с денежными суммами в числовом формате с плавающей точкой. Вместо этого 
попробуем выявить дублирование в приведенном выше фрагменте кода. (Мы 
обнаружили три таких места, но вы можете найти и больше.) 

Ҷто же мы нашли? А вот что. 

Прежде всего, в рассматриваемом здесь коде явно проявляется дублирование 
обработки отрицательных чисел методом копирования и вставки. Этот недоста- 
ток можно устранить, введя еще одну функцию, как показано ниже. 


ЧеЁ Ғогтаї апоипі (уа1їџое) 
геѕиі = ѕргіпі# ("%10.2#", уа1ае.арз) 
1Е уа|1ае < 0 
геѕоіі + "-" 
е] зе 
гези + 
епа 
епа 
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её рг1пЕ ра1апсе (ассоџпі) 
ру1пЕЁЕ "”реріѕ: %10.2#\п", ассоџпё .Ядеріїѕ 
ргіпіЁ "Сгеаііѕ: 510.2#\п", ассоцпі.сгеаіізѕ 
ргіпіЁ "Еееѕ: %5\п", Ғогта апмоцп+ (ассоипі.Ёееѕ) 
РЕТИЕЕ "==" 
ргіпіЁ "Ва1апсе: %5\п", Ғогта атоцп® (ассоип®.Ба1апсе) 
епа 


Еще одно дублирование проявляется в повторении ширины поля во всех вы- 
зовах функции ргіпёѓ (). Такое дублирование можно было бы устранить, введя 
константу и передавая ее при каждом вызове данной функции, но почему бы не 
воспользоваться уже имеющейся функцией? Ниже показано, как это делается. 


бе Ғогтаё атоцпЕ (уаічое) 
геѕиіё = зрг1пЕЕ("%10.2Е", уа]1ое.аз) 
1Е уа1ае < 0 
хеза1 + "-" 
е1зе 
я 7 
епа 
епа 


де? рг1пЕ ра1апсе (ассоип®) 
ргіпёЁ "”Рерієѕ: %5\п", Ғогтаї амочпе (ассоцпё.адеріїзѕ) 
ргіпёЁ "СгеаӢібѕ: %5\п", Еогтае атоипї (ассоцпё.сгеаіѓізѕ) 
ргіпёЁ "Реез: %5\п", Ғогтаї аточпе (ассоцпі.Ғееѕ) 
ргіпії? " ——\п" 
ргіпёЁ "Ва1апсе: %5\п", Ғогтаё атоџпі (ассоџпё.ра1апсе) 
епа 


Еще что-нибудь? А что если клиент попросит ввести дополнительные пробе- 
лы между метками и числами? Тогда придется изменять пять строк кода. Устра- 
ним и это дублирование: 


её Ғогтаї аптоопї (уаічце) 
геѕиіё = ѕргіпі#Ё ("%10.2Е#", уа1ае.аЪз) 
ЇЁ уа1ое < 0 
геѕиціс + "-" 
е] зе 
тез" 
епа 
епа 


её ргіпі 11пе (1аре1, уа1че) 
ргіпёЁ "%-95%5\п", 1аре1, уа1че 
епа 


её герогі 11пе (1абе1, атоопі) 
ргіпї 11пе (1аре1 + ":", Еогта® аточпе (атоцпіё)) 
епа 


Чеё ргіпі ра1апсе (ассопп®) 
герогі 1іпе ("Ррерібѕ", ассоцпе.аер1+$) 
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героге 11пе ("СгеаӢіїѕ", ассоцп®.сгеа1*$) 

герогї 11пе ("Геез", ассоцпі. Еее$) 

реа ве" =") 

героі 11пе ("Ва]апсе", ассоип®.ра1апсе) 
епа 


Если потребуется изменить форматирование денежных сумм, то при- 
дется внести соответствующие коррективы в функцию Ғогтає аточпі (). 
А если потребуется изменить формат меток — внести коррективы в функцию 
герогї 11пе(). 

Тем не менее неявное нарушение принципа ОКУ все еще остается, поскольку 
количество дефисов в разделительной линии связано с шириной поля денежной 
суммы. Хотя совпадение неточное: в данном случае поле короче на один символ, 
поэтому любые конечные дефисы выступают за пределы столбца. Но это намере- 
ние клиента, отличающееся от фактического форматирования денежных сумм. 


Не всякое дублирование кода является дублированием знаний 


В приложении для заказа вин через Интернет требуется зафиксировать и 
проверить возраст клиента, а также количество заказанного вина. По требова- 
нию владельца веб-сайта и то и другое должно быть представлено в виде поло- 
жительных чисел. Поэтому соответствующие проверки достоверности реализу- 
ются в коде следующим образом: 


её уа1ідаёе аде (уа1ще) : 
уаіідаїе уре (уа1џе, :1п%едег) 
уа1ідаѓе тіп іпіедег (уа1че, 0) 


её \уа11Чафе аџапііёу (уа1џе) : 
уа1ідаёе іуре (уа1џе, :1п$едехг) 
уа1ідаїе тіп іпіедег (уа1ще, 0) 


Во время проверки исходного кода местный всезнайка может отбраковать 
приведенный выше фрагмент, заявив, что он нарушает принцип ОКУ — ведь 
тела обеих функций одинаковы. Но он не прав! Код действительно одинаковый, 
но знания, которые он представляет, — разные. Ведь обе функции проверяют на 
достоверность разные данные, просто в данном случае это делается по одинако- 
вым правилам. Это всего лишь совпадение, а не дублирование. 


ДУБЛИРОВАНИЕ В ДОКУМЕНТАЦИИ 


Неизвестно откуда, но некогда родился миф, что все функции должны быть 
снабжены комментариями. Те, кто верят в эту нелепость, создают нечто похожее 
на приведенный ниже код. 


# Вычислить комиссионные по этому счету. 

# 

# * Каждый возвращаемый чек стоит $20. 

# * Если перерасход денег на счете длится больше 3 дней, 
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# насчитать пеню $10 за каждый день. 
# * Если средний остаток на счете превышает $2,000, 
# сократить комиссионные на 50%. 


ЧеЁ Геез (а) 
Е = 0 
іЁ а.геіиогпеа сһеск соџпі > 0 
Е += 20 * а.геіџгпеа сһеск соцпі 
епа 
іЁ а.оуегагаЁі дауѕ > 3З 
Е += 10*а.оуегагаїї аауѕ 


епа 

іЁ а.ауегаде ра1апсе > 2 000 
Е /= 2 

епа 

Е 


епа 


Назначение приведенной выше функции указано дважды: один раз — в ком- 
ментариях к ней, второй раз — в ее исходном коде. Если заказчик изменит по- 
рядок начисления комиссионных, обновить придется как исходный код, так и 
комментарии. И можно гарантировать, что со временем комментарии окажутся 
несогласованными с исходным кодом. 

Непременно задайтесь вопросом: какие комментарии вводятся в исходный 
код? На наш взгляд, комментарии лишь возмещают неудачное именование и 
компоновку. Так, в приведенном ниже фрагменте кода имена ясно указывают 
назначение элементов кода. И если кому-нибудь понадобятся подробности, то 
он обнаружит их в исходном тексте. Именно так и соблюдается принцип ОКУ! 


её са1со1афе ассоопі Ееез$ (ассоџопё) 
Геез = 20*ассоцпі.гесигпеа сһеск соцпі 
Ғееѕ += 10*ассоцпі.оуегӣга# дауѕ 1# ассоцпе.оуегагаЕЕ Чауз > 3 
Ееез /= 2 іҒ ассоџпё.ауегаде ра1апсе > 2 000 
Ғееѕ 

епа 


Нарушение принципа ОВУ в данных 


Структуры данных представляют знания, и они тоже могут противоречить 
принципу ОКУ. Рассмотрим в качестве примера следующий класс, пре-дставля- 
ющий прямую линию: 

с1аз8 Ііпе { 

Ро1пЕ ѕіёагі; 
Ро1п® епа; 
дӢооЬ1е 1епоеП; 

}; 

На первый взгляд, такое определение класса может показаться вполне обос- 
нованным. В нем явно определены поля для начальной и конечной точек пря- 
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мой линии, а также ее длины, даже если она нулевая. Но в нем все равно при- 
сутствует дублирование. Ведь длина прямой линии определяется ее начальной и 
конечной точками. Достаточно изменить одну из них, чтобы изменилась длина 
прямой линии. Поэтому поле длины лучше сделать вычисляемым, как показано 
ниже. 


с1азз Ііпе { 

Роіпі зіёагі; 

Роіпі епа; 

дӢооџр1е 1епдіїһ () { геіцгп ѕёагїі.аіѕіапсетТо (епа) ; } 
}; 


На последующей стадии процесса разработки, возможно, придется пойти на 
нарушение принципа ОВУ из соображений производительности. Зачастую это 
происходит в том случае, когда требуется кешировать данные, чтобы исключить 
повторение затратных операций. И здесь самое главное — локализовать отри- 
цательное влияние, чтобы оно не распространялось наружу. Отличия должны 
быть заметны лишь в методах класса, как показано ниже. 


с]азз Г1пе { 
рг1луаее АоцЬ1е 1епдіһ; 
рглуаее Роіпі зфаг(; 
ргіуаёе Роіпі епа; 


рчр1іс Г1пе (Роіпі ѕёагі, Роіпі епа) { 
ҰҺіз.ѕіагі = ѕіагі; 
єһҺіз.епа = епа; 
са1ісијаіе1[епдаіћ (); 

} 


// Открытые методы 
уоіа ѕеіѕіагі (Ро1пе р) { +һћізѕ.ѕіагі = р; са1си1аѓёе1Іепаіћ (); } 


уоіа ѕеїЕпа (Роіпі р) { ©&һіз.епа = р; саісиіаіе1епдаіћ (); } 
Ро1пе адеїбіагі+ () { геёоџгп ѕіагі; } 

Роіпі деїЕпа () { геёогп епа; } 

дӢочЬ1е деі1епдаіпћ () { гебагп 1епаіһ; } 


рг1уафе уоіа са1си1аіеГепаїһћ () { 
єҺіѕ.Іепадїһ = ѕбагіе.аіѕёапсетТо (епа); 


}; 


В данном примере также наглядно демонстрируется следующее важное по- 
ложение: всякий раз, когда модуль раскрывает структуру данных, весь исполь- 
зующий ее код привязывается к реализации этого модуля. Поэтому для чтения 
и записи содержимого свойств или полей объекта следует всегда пользоваться 
функциями доступа там, где это возможно. Благодаря этому впоследствии упро- 
щается внедрение дополнительных функциональных возможностей. 
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Такое употребление функций доступа тесно связано с принципом единообра- 
зия доступа, описанным Мейером в книге ОБес!-Опешей ЗоЙате СопятисНоп 
[Меу97] и гласящим следующее: 


Все службы, предоставляемые модулем, должны быть доступны с помо- 
щью единообразной системы обозначений, которая не зависит от того, 
как они реализуются: через хранение в памяти или вычисление. 


ПРЕДСТАВИТЕЛЬНОЕ ДУБЛИРОВАНИЕ 


Написанный вами код взаимодействует с внешним миром: с другими библи- 
отеками — через интерфейсы прикладного программирования (АРІ), с другими 
службами — через удаленные вызовы, с данными из внешних источников и т.д. 
И всякий раз, когда вы организуете такое взаимодействие, так или иначе нару- 
шаете принцип ОКУ. Ведь в вашем коде требуются знания, которые присутству- 
ют во внешнем объекте, в том числе АРІ, схема базы данных, коды ошибок и 
пр. Дублирование в данном случае состоит в том, что обеим сторонам взаимо- 
действия (вашему коду и внешнему объекту) необходимо знать представление 
их интерфейсов. Достаточно изменить его у одной стороны, и на другой стороне 
все будет нарушено. И хотя такое дублирование неизбежно, его все же можно 
умерить. Ниже описывается ряд стратегий, позволяющих добиться этого. 


Дублирование через внутренние АР! 


Что касается внутренних АРІ, то следует найти такие инструментальные 
средства, которые позволяют указать интерфейс прикладного программирова- 
ния в некоторого рода нейтральном формате. Как правило, такие инструмен- 
тальные средства автоматически генерируют документацию, функциональные 
тексты, имитирующие АР] и их клиентов, причем последних — на самых разных 
языках. В идеальном случае такое инструментальное средство способно сохра- 
нять внутренние АРІ в центральном хранилище, делая их общедоступными для 
команд разработчиков. 


Дублирование через внешние АР! 


Все чаще можно обнаружить, что открытые АРІ формально документирова- 
ны с использованием таких средств, как, например, ОрепАРГ. Это дает возмож- 
ность импортировать спецификации АРІ в локальные инструментальные сред- 
ства и более надежно интегрировать их с соответствующими службами. 

Если вам не удастся найти подходящую спецификацию, рассмотрите возмож- 
ность создать и опубликовать ее самостоятельно. Это не только принесет пользу 
другим, но и поможет ее сопровождению. 


4 См. по адресу ВЕЕрз : / /9іёһир.сом/ОАІ/ОрепАРІ-ЅресіЁісаїіоп. 
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Дублирование через источники данных 


Многие источники данных позволяют выполнять самоанализ своих схем 
данных. Этим обстоятельством можно воспользоваться, чтобы по большей час- 
ти исключить дублирование между источниками данных и прикладным кодом. 
Вместо того чтобы писать вручную код для работы с данными из подобных ис- 
точников, можно сформировать контейнеры непосредственно из схемы данных. 
Многие каркасы могут сделать эту рутинную работу вместо вас. 

Имеется и другая, на наш взгляд, более предпочтительная возможность. 
Вместо того чтобы писать код, представляющий внешние данные в фиксирован- 
ной структуре (например, экземпляре структуры или классе), достаточно ввести 
их в структуру данных в виде пар “ключ-значение”, которая может называться 
отображением, хешем, словарем или даже объектом, в зависимости от конкрет- 
ного языка программирования. 

Само по себе это рискованно, поскольку необходимо знать, какие именно 
данные следует обрабатывать, а от этого существенно снижается уровень бе- 
зопасности. Поэтому рекомендуется вводить в такое решение второй уровень 
в виде простого табличного набора тестов для проверки достоверности, чтобы 
выяснить, содержит ли созданное отображение требующиеся данные в нужном 
формате. Вполне возможно, что имеющемуся у вас инструментальному средству 
документирования прикладных интерфейсов АРІ удастся сформировать такой 
набор тестов. 


ДУБЛИРОВАНИЕ СРЕДИ РАЗРАБОТЧИКОВ 


Едва ли не самый трудный для обнаружения и устранения вид дублирова- 
ния происходит между разными разработчиками в проекте. Неумышленно мо- 
гут быть сдублированы целые наборы функциональных возможностей, годами 
оставаясь необнаруженными и существенно затрудняя сопровождение. Нам 
приходилось слышать, как государственные вычислительные системы США об- 
следовались на соблюдение требований в связи с наступлением 2000 года. Как 
показала проверка, более 10 тысяч программ содержали разные версии кода 
проверки номера социального обеспечения. 

На самом общем уровне с дублированием можно справиться, организовав 
сильную команду, сплоченную хорошо налаженным общением. А вот на уров- 
не модуля данная проблема проявляется не так явно. Ведь зачастую требуются 
функциональные возможности или данные, которые не входят в очевидные гра- 
ницы ответственности, и поэтому они могут быть многократно реализованы. 
Для борьбы с дублированием на этом уровне, на наш взгляд, лучше всего поощ- 
рять активное и частое общение разработчиков друг с другом. 

Возможно, стоит проводить ежедневные “летучки” по методике Ѕсгит или 
организовать форумы (например, через каналы корпоративного обмена сообще- 
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ниями типа $]асК). Подобным образом обеспечивается ненавязчивое общение 
(даже во многих местах) с постоянным хранением архивов всего сказанного. 

Одного из членов команды можно назначить в качестве библиотекаря проек- 
та, вменив ему в обязанность содействовать обмену знаниями. Выделите цент- 
ральное место в дереве исходного кода, где можно было бы размещать служеб- 
ные программы и сценарии, и возьмите себе за правило читать исходный код 
и документацию других разработчиков как неформально, так и во время про- 
смотров исходного кода. Ведь так вы сами учитесь у них, а не подглядываете за 
ними. И не забывайте, что доступ к исходному коду должен быть взаимным — 
не смущайте тех, кто внимательно изучает вам исходный код, а возможно, и 
копается в нем. 


Упрощайте повторное использование исходного кода 


Старайтесь взрастить такую среду, где было бы проще находить и повторно 
использовать существующий исходный код, чем писать его самому. Если это 
нелегко сделать, люди вообще не будут так поступать. Если же вы не умеете 
повторно пользоваться исходным кодом, то рискуете дублировать знания. 


Другие разделы, связанные с данной темой 
® Тема 8. Сущность качественного проектирования. 


в Тема 28. Развязывание, глава 5 “Гибкость или ломкость”, 


Тема 32. Конфигурирование, глава 5 “Гибкость или ломкость”. 


> 


® Тема 38. Программирование по совпадению, глава 7 “По ходу кодирования”. 


е 


Тема 40. Рефакторинг, глава 7 “По ходу кодирования”. 


ИА ЮУ МДИ. ВАНО ОА В КЛЫК ЛНАМ У УАН ТНА НИ еек Н МТРА А ТМК ДОРН о А АА МАО АСА ММ АММА Я 


ОРТОГОНАЛЬНОСТЬ 


Понятие ортогональности имеет решающее значение для создания таких 
систем, которые легко проектировать, строить, тестировать и расширять. Но 
это понятие редко изучают непосредственно. Зачастую оно считается неявным 
свойством совсем других изучаемых приемов и методов, а это ошибка. Научив- 
шись применять принцип ортогональности непосредственно, вы сразу же заме- 
тите, насколько повысится качество создаваемой вами системы. 


Что ТАКОЕ ОРТОГОНАЛЬНОСТЬ 


Термин ортогональность заимствован из геометрии, где две линии называ- 
ются ортогональными, если они пересекаются под прямым углом (например, 


70 Глава 2 • Прагматичный подход 


оси на графике). А в терминологии векторов две подобные линии считаются 
независимыми. Так, линия №1 на приведенной ниже диаграмме направлена на 
север, и она никоим образом не изменяет положение на восток или запад. А ли- 
ния №2 направлена на восток, а не на север или юг. 


весло 


В вычислительной технике термин ортогональность стал означать незави- 
симость, или развязывание. Два или более компонента считаются ортогональ- 
ными (не связанными), если изменения в одном из них не оказывают никакого 
влияния на остальные компоненты системы. В грамотно спроектированной сис- 
теме исходный код базы данных будет ортогональным по отношению к пользо- 
вательскому интерфейсу. Это означает, что пользовательский интерфейс можно 
изменить, не оказывая никакого влияния на базу данных, а последнюю — заме- 
нить, не меняя первый. Но прежде чем обсуждать преимущества ортогональных 
систем, рассмотрим систему, которая не является ортогональной. 


Неортогональная система 


Представьте, что вы совершаете вертолетную экскурсию по Большому Каньо- 
ну, шт. Колорадо, и вдруг пилот, съевший, очевидно, по ошибке рыбу на обед, 
застонал и потерял сознание. К счастью или несчастью, но он оставил вертолет 
без управления зависшим на высоте около 30 м над землей. 

По счастливой случайности вам довелось прочитать прошлым вечером стра- 
ницу Википедии о вертолетах, и поэтому вам известно, что у вертолета имеются 
четыре основных рычага управления. В частности, вы берете ручку продольно- 
поперечного управления циклическим шагом несущего винта в правую руку и 
перемещаете ее так, чтобы вертолет двигался в нужном направлении. А в левую 
руку берете рычаг управления общим шагом несущего винта и тянете его на 
себя, чтобы увеличить шаг на всех лопастях и, таким образом, набрать высоту. 
На конце рычага управления общим шагом находится рукоятка управления га- 
зом. Наконец, двумя педалями вы можете изменить силу тяги хвостового винта, 
чтобы повернуть вертолет. 

“Легко! — подумаете вы. — Плавно опусти ручку продольно-поперечного уп- 
равления циклическим шагом несущего винта и аккуратно приземлишься, ге- 
рой”. Но, попытавшись это сделать, вы обнаружите, что не все так просто. Верто- 
лет нырнет носом вниз и начнет передвигаться по спирали влево. И неожиданно 
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для вас выяснится, что каждое управляющее воздействие на систему, в которой 
вы летите, имеет побочные эффекты. Стоит опустить рычаг в левой руке, и вам 
придется добавить уравновешивающее обратное движение ручкой в правой руке 
и нажатием правой педали. Но и тогда каждое из этих изменений снова окажет 
влияние на все остальные органы управления. Таким образом, вы вдруг обнару- 
жите, что пытаетесь манипулировать невероятно сложной системой, где каждое 
изменение оказывает влияние на все остальные входные воздействия. В итоге на 
вас падает необычайная нагрузка, поскольку ваши руки и ноги постоянно дви- 
гаются, пытаясь уравновесить все взаимодействующие силы. И это означает, что 
органы управления вертолетом решительно неортогональны. 


ПРЕИМУЩЕСТВА ОРТОГОНАЛЬНОСТИ 


Как демонстрирует приведенный выше пример вертолета, неортогональным 
системам присущи большая сложность при внесении изменений и управлении. 
Если компоненты какой-нибудь системы в высшей степени взаимозависимы, то 
говорить о локальном исправлении ошибок не приходится вовсе. 


Исключайте взаимное влияние несвязанных 
компонентов системы 


Компоненты системы следует разрабатывать таким образом, чтобы они были 
самостоятельными, независимыми и имели единственное, вполне определенное 
назначение, т.е. то, что Юрдон (Уои!г4оп) и Константин (Сопѕќапііпе) называют 
в своей книге Ѕіғисѓигей Реѕіеп: Еипдаатепаб оў а Гіѕсіріпе оў Сотриег Ртортат 
апа $уѕіетѕ Реѕірп [УС79] сцеплением (соһеѕіоп). Если компоненты обособлены 
один от другого, то один из них можно свободно изменить, не опасаясь затро- 
нуть все остальные. При этом вы можете быть уверены, что не внесете никаких 
осложнений, способных распространиться по всей системе, если только не из- 
меняете внешние интерфейсы компонента. Проектируя ортогональные системы, 
вы получаете два основных преимущества: повышение производительности и 
снижение рисков. 


Повышение производительности 
Это преимущество означает следующее. 


® Изменения локализуются, поэтому время разработки и тестирования со- 
кращается. Относительно небольшие, самостоятельные компоненты на- 
писать проще, чем один крупный блок кода. Простые компоненты мож- 
но спроектировать, запрограммировать, протестировать, а затем забыть 
о них, поскольку не нужно постоянно изменять уже существующий код, 
когда вводится новый. 
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® Ортогональный метод проектирования способствует повторному исполь- 
зованию. Так, если на компоненты возлагаются конкретные, вполне оп- 
ределенные обязанности, их можно объединять с новыми компонентами 
даже так, как того не предвидели те, кто их первоначально реализовывал. 
Чем более слабо связаны системы, тем легче они поддаются перекомпонов- 
ке и перепроектированию. 


® Объединение ортогональных компонентов дает едва заметный выигрыш в 
производительности. Допустим, один компонент выполняет М отдельных 
операций, а другой компонент — М операций. Если оба эти компонента 
ортогональны и объединяются, то в итоге получается система, выполняю- 
щая МхМ операций. Но если оба компонента не ортогональны, то проис- 
ходит наложение, а в итоге выполняется меньше операций. Таким образом, 
объединяя ортогональные компоненты, можно получить больше функцио- 
нальных возможностей на единицу объема выполненных работ. 


Сокращение риска 


При ортогональном подходе сокращаются риски, присущие любой разработ- 
ке и состоящие в следующем. 


» Неисправные разделы кода изолируются. Если какой-нибудь модуль пов- 
режден, вероятность, что признаки его ущербности распространятся на 
остальную систему, становится меньше при ортогональном подходе. Кро- 
ме того, такой модуль проще вычленить и заменить каким-нибудь новым 
и вполне работоспособным модулем. 


е Конечная система менее уязвима. А мелкие изменения и исправления в 
конкретной области или любые вносимые вами осложнения ограничива- 
ются данной областью. 


е Ортогональная система лучше поддается тестированию, поскольку ее про- 
ще спроектировать и провести тесты ее компонентов. 


ә Вас ничто не будет тесно связывать с конкретным поставщиком, програм- 
мным продуктом или платформой, поскольку интерфейсы с этими сторон- 
ними компонентами ограничиваются небольшими частями общей разра- 
ботки. 


А теперь рассмотрим некоторые способы применения принципа ортогональ- 
ности на практике. 
ПРОЕКТИРОВАНИЕ 


Большинству разработчиков хорошо известна потребность в проектиро- 
вании ортогональных систем, хотя для описания данного процесса они могут 
пользоваться такими терминами, как модульное, компонентное и многоуровневое 
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проектирование. Системы должны состоять из ряда взаимодействующих моду- 
лей, каждый из которых реализует независимые друг от друга функциональ- 
ные возможности. Иногда такие компоненты организуются в отдельные уров- 
ни, каждый из которых обеспечивает определенный уровень абстракции. Такой 
многоуровневый подход оказывается весьма эффективным для проектирования 
ортогональных систем. А поскольку на каждом уровне используются только те 
абстракции, которые обеспечиваются нижележащими уровнями, то появляется 
возможность очень гибко изменять базовые реализации, не оказывая никакого 
влияния на исходный код. Многоуровневое представление позволяет также сни- 
зить риск появления бесконтрольных зависимостей между модулями. Зачастую 
многоуровневое представление системы выражается в виде диаграмм, аналогич- 
ных приведенной ниже. 


Пользовательский интерфейс 
Доступ к базе | 
данных | 


КЕЛЕСЕ ЕЕРЕЕ 


е анма анн понты етае. е ол вареное ооо палок тать ответим тесен 


Авторизация | Бизнес-логика 


- 
і 


МРЧПАРБИИНЫ РЕКС противно обо ОЬ ЫЧ ИОРАН 


Каркас приложений 


РРР елена иконе инте альянс ленью доводя ть ттт ты жать исто 


Стандартные библиотеки 


пя ладан кот ем лески лая пиши иретичи а Ааа ежедневки воле читать Чем ме фт ас. рт 


Контейнерные службы 


Проверить проектирование системы на ортогональность совсем не трудно. 
Как только вы наметите компоненты системы, задайте себе следующий воп- 
рос: если я внесу коренные изменения в требования к конкретной функици, на 
какое количество модулей это повлияет? В ортогональной системе ответ на этот 
вопрос должен быть “один””. Так, перемещение экранной кнопки в графичес- 
ком пользовательском интерфейсе не должно требовать изменений в схеме базы 
данных, а добавление контекстно-зависимой справки — изменений в подсистеме 
выписки счетов. 

Рассмотрим в качестве примера сложную систему управления и текущего кон- 
троля нагревательной установки. В первоначальном требовании было указано 
обязательное наличие пользовательского интерфейса, но затем это требование 
было дополнено интерфейсом для мобильных устройств, позволяющим инже- 
нерам постоянно контролировать основные параметры процесса нагрева. Чтобы 


> На практике не все оказывается так просто. Лишь при очень счастливом стечении обстоя- 
тельств большинство изменений в реальных требованиях не окажет влияние на многие функ- 
ции в системе. Но если анализировать изменения по функциям, то каждое функциональное 
изменение в идеальном случае должно все же оказывать влияние лишь на один модуль. 
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удовлетворить этим требованиям, в ортогонально спроектированной системе 
придется внести изменения лишь в модули, которые непосредственно связаны 
с пользовательским интерфейсом, тогда как базовая логика управления нагрева- 
тельной установки останется без изменения. В самом деле, если структура такой 
системы тщательно спроектирована, то обеспечить поддержку обоих интерфей- 
сов удастся с помощью одной и той же кодовой базы. 

Спросите себя: насколько структура вашей системы отделена от изменений 
в реальном мире? Так, если вы используете номер телефона в качестве иденти- 
фикатора клиента, то что произойдет, если телефонная компания переназначит 
телефонные коды городов, областей и регионов? Почтовые индексы, номера со- 
циального обеспечения или паспортов, адреса электронной почты и домены Ин- 
тернета — все это внешние идентификаторы, которые вам не подвластны и могут 
измениться в любой момент по какой угодно причине. Поэтому ни в коем случае 
не полагайтесь на свойства объектов, неподвластные вашему контролю. 


ИНСТРУМЕНТАЛЬНЫЕ СРЕДСТВА И БИБЛИОТЕКИ 


Старайтесь сохранять ортогональность своей системы, внедряя сторонние 
инструментальные средства и библиотеки. Благоразумно выбирайте подходя- 
щие технологии. 

Внедряя набор инструментальных средств (или даже библиотеку от других 
членов команды), спросите себя: какие нежелательные изменения в исходном 
коде это может повлечь? Так, если схема сохраняемости объектов оказывается 
прозрачной, то она спроектирована ортогонально. Если же требуется создавать 
объекты (или получать к ним доступ) каким-то особым образом, то схема их 
сохраняемости неортогональна. Отделение таких подробностей реализации от 
вашего кода дает дополнительное преимущество, упрощающее поставщикам 
внедряемых средств внесение изменений в будущем. 

Система ЕЈВ (Ещегри$е Јауа Веапѕ — корпоративные компоненты ]ауа Веапѕ) 
служит интересным примером ортогональности. В большинстве ориентирован- 
ных на транзакции систем на прикладной код возлагается обязанность обоз- 
начить начало и конец каждой транзакции. В системе Е]В такая информация 
выражается декларативно в виде аннотаций и за пределами методов, выпол- 
няющих всю необходимую работу. Один и тот же прикладной код может быть 
выполнен без всяких изменений в разных средах транзакций ЕЈВ. 

В известном смысле система Е]В служит наглядным примером применения 
проектного шаблона “Декоратор” (Юесогаќог), по которому функциональные 
возможности вводятся в компоненты системы без их изменения. Такой стиль 
программирования может быть реализован практически в любом языке про- 
граммирования и совсем не обязательно требует наличия каркаса или библи- 
отеки. Он требует лишь соблюдать определенную дисциплину в процессе про- 
граммирования. 
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КодировАНИЕ 


Всякий раз, когда вы пишете код, вы рискуете убавить ортогональность свое- 
го приложения. И если не контролировать постоянно не только свои действия, 
но и более крупный контекст приложения, то можно неумышленно сдублиро- 
вать функциональные возможности в каком-нибудь другом модуле или выра- 
зить существующие знания дважды. 

Ниже вкратце описываются некоторые методики, с помощью которых можно 
поддерживать ортогональность. 


ә Поддерживайте свой код развязанным. Пишите код экономно, создавая 
модули, не раскрывающие ничего лишнего другим модулям и не опираю- 
щиеся на их реализации. Старайтесь соблюдать закон Деметры, поясняе- 
мый в разделе “Тема 28. Развязывание” главы 5. Если требуется изменить 
состояние объекта, добейтесь того, чтобы он делал это автоматически. По- 
добным образом ваш код останется обособленным от реализации другого 
кода и тем самым повысятся шансы сохранить ортогональность того, что 
вы проектируете. 


® Избегайте глобальных данных. Всякий раз, когда в вашем коде выполняет- 
ся обращение к глобальным данным, он привязывается к другим компо- 
нентам, совместно использующим эти же данные. Даже глобальные пере- 
менные, предназначенные только для чтения, могут привести к осложне- 
ниям (например, в том случае, если срочно потребуется сделать ваш код 
многопоточным). В общем, если вы явно передаете любой требующийся 
контекст своим модулям, ваш код будет легче понять и сопровождать. 
В объектно-ориентированных приложениях контекст обычно передается в 
виде параметров конструкторам объектов. А в другом коде можно создать 
структуры, содержащие контекст, и передавать ссылки на них. 


® Проектный шаблон Синглтон (ЅіпрІеѓоп), описанный в книге ШЮеѕіғи 
РаНетиз: Еетеп о} Кеиза Ме ОБјесі-Отіепіеӣ $оймате [СНЈУ95], — это 
средство, гарантирующее существование лишь одного экземпляра объекта 
конкретного класса. Многие разработчики пользуются полученными та- 
ким образом одиночными объектами в качестве глобальных переменных 
(особенно в таких языках, как Јауа, где глобальные переменные иным об- 
разом не поддерживаются). Пользуйтесь, однако, синглтонами аккуратно, 
поскольку они также могут привести к ненужному связыванию. 


® Избегайте сходных функций. Зачастую встречается ряд функций, очень по- 
хожих, например, тем, что они совместно используют общий код в начале 
и в конце, хотя имеют разные алгоритмы в центре. Такое дублирование 
кода служит явным признаком структурных недостатков. Более хорошую 


реализацию может предоставить проектный шаблон “Стратегия” (Ѕігаѓеру), 
[СНЈУ95]. 
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Приобретите привычку постоянно осматривать свой код критическим взгля- 
дом. Ищите возможности улучшить его структуру и ортогональность. Такой 
процесс называется рефакторингом и настолько важен, что мы посвятили ему 
отдельный раздел “Тема 40. Рефакторинг” в главе 7. 


ТЕСТИРОВАНИЕ 


Ортогонально спроектированную и реализованную систему легче тестиро- 
вать. Взаимодействия компонентов такой системы формализованы и ограни- 
чены, и поэтому на уровне отдельных модулей можно произвести большую 
часть тестирования системы. И это хорошо, поскольку определить и выполнить 
модульное (или блочное) тестирование намного проще, чем комплексное. При 
этом предполагается, что подобные тесты должны проводиться автоматически 
как часть обычного процесса сборки (см. раздел “Тема 41. Тестировать, чтобы 
кодировать” главы 7). 

Написание модульных тестов само по себе является интересной проверкой 
ортогональности. Что же требуется для составления и выполнения модульного 
теста? Приходится ли для этого импортировать львиную долю остального кода 
системы? Если да, то можно считать, что обнаружен модуль, который недоста- 
точно отвязан от остальной системы. 

Но устранение программных ошибок также является удобным моментом 
для оценивания ортогональности всей системы в целом. Когда вы обнаружите 
ошибку, оцените, насколько локализовано ее исправление. Изменяется ли при 
этом лишь один модуль, или же изменения распространяются по всей системе? 
Если вы вносите изменение, исправляет ли оно все ошибки или же загадочным 
образом возникают другие ошибки? Это удобная возможность задействовать 
автоматизацию. Если вы пользуетесь системой контроля версий исходного кода 
(а вы ею все равно станете пользоваться, как только прочитаете раздел “Тема 19. 
Контроль версий” главы 3), отмечайте исправления ошибок, когда будете снова 
проверять код после тестирования. И тогда вы сможете составлять и просмат- 
ривать ежемесячные отчеты, анализируя тенденции в целом ряде исходных фай- 
лов, на которые повлияло исправление каждой ошибки. 


ДокумЕНТАЦИЯ 


Как ни странно, принцип ортогональности распространяется и на докумен- 
тацию. В данном случае ортогональность проявляется в плоскости координат 
содержания и представления. Если документация истинно ортогональная, ее 
внешний вид удается изменить коренным образом, совершенно не меняя со- 
держание. Для этой цели в текстовых редакторах предоставляются таблицы 
стилей и макрокоманды. Мы лично предпочитаем пользоваться такой системой 
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разметки, как МагК4омт. При составлении документации мы уделяем основное 
внимание только содержанию, оставляя представление тому инструментально- 
му средству, которое воспроизводит документацию. 


КАК УЖИВАТЬСЯ С ОРТОГОНАЛЬНОСТЬЮ 


Ортогональность тесно связана с принципом ОКУ, описанным ранее в раз- 
деле “Тема 9. ОКҮ — пороки дублирования”. Соблюдая принцип ОКУ, вы ищете 
возможность свести к минимуму дублирование в системе, а соблюдая принцип 
ортогональности — сократить взаимозависимость компонентов системы. Не- 
смотря на то что само слово “ортогональность” как-то не укладывается в обыч- 
ные представления программиста, придерживаясь принципа, который это слово 
обозначает, наряду с принципом ОБУ, вы непременно обнаружите, что разраба- 
тываете более гибкую, понятную и простую для отладки, тестирования и сопро- 
вождения системы. 

Если вас привлекли к работе над проектом, где остальные его участники от- 
чаянно борются за то, чтобы внести изменения, и где каждое изменение может 
привести к тому, что дело не заладится и в четырех других местах, вспомните 
об описанном ранее кошмаре с управлением вертолетом. Вероятнее всего, такой 
проект спланирован и запрограммирован неортогонально. 

И, если вы пилотируете вертолет, не ешьте рыбу... 


Другие разделы, связанные с данной темой 
• Тема 3. Программная энтропия, глава 1 “Философия прагматизма”. 
• Тема 8. Сущность качественного проектирования. 
® Тема 11. Обратимость. 
е Тема 28. Развязывание, глава 5 “Гибкость или ломкость”. 
е Тема 31. Налог на наследование, глава 5 “Гибкость или ломкость” 
® Тема 33. Разрывание временного связывания, глава 6 “Параллельность”. 


• Тема 34. Общее состояние — неверное состояние, глава 6 “Параллель- 
» 
ность”. 


® Тема 36. Классные доски, глава 6 “Параллельность” 


Задачи 


® Выясните, чем инструментальные средства с графическим пользователь- 
ским интерфейсом отличаются от небольших, но легко объединяемых в 


6 ш о 
На самом деле английское издание этой книги было написано в системе разметки 
Магкдоутп и напечатано в типографии непосредственно из исходного файла МагК4о\мт. 
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командной строке утилит. Какая из этих разновидностей инструменталь- 
ных средств оказывается более ортогональной и почему? Какой из них 
удобнее пользоваться в тех целях, для которых она непосредственно пред- 
назначена? Какую из них легче объединить с другими инструментальными 
средствами для решения новых задач? И какую из них легче изучить? 


В языке С++ поддерживается множественное наследование, тогда как в 
языке Јауа допускается реализация в классе нескольких интерфейсов, а в 
языке КиБу имеются миксины. Какое влияние оказывает применение этих 
языковых средств на ортогональность? Имеются ли какие-нибудь отличия 
в применении множественного наследования и многих интерфейсов, деле- 
гирования и наследования? 


Упражнения 


1. Допустим, вам было предложено реализовать построчное чтение исходно- 
го файла. Каждую строку вы должны разбить на поля. Какой из приведен- 
ных ниже определений псевдоклассов, по вашему мнению, является более 


ортогональным?” 
с1азз 5р11{1 { 
сопзЕгасфохг (Ё11еМапе) # открывает файл для чтения 
де# геаамехі1іпе () # переходит к следующей строке 
аеЕ деїЕ1іе1а (п) # возвращает п-е поле из текущей строки 
} 
ИЛИ 


с1аѕѕ $р11е2 { 


сопѕігисіог (11пе) # разбивает строку на поля 
аеЁ аеіЕіе1а (п) # возвращает п-е поле из текущей строки 


2. Чем объектно-ориентированные и функциональные языки программирова- 
ния отличаются в смысле ортогональности? Присущи ли эти отличия самим 
языкам или же только тому способу, каким люди ими пользуются? 


Я С ДО МАТА УДАА АИО С И ЕО СВ ЕВ ОО К 


5 Возможные ответы на это и все остальные упражнения в данной книге см. в прило- 
жении В. 
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ОБРАТИМОСТЬ 


“Нет ничего опаснее идеи, если это все, что у вас есть”. 


— Эмиль-Огюст Шартье, псевдоним “Ален”, 
О религии (Ртороѕ ѕиг Іа теЇісіоп), 1938 г. 


Инженеры предпочитают простые, однозначные решения задач. Контрольные 
работы по математике, позволяющие с полной уверенностью заявить, что х = 2, 
намного более удобны, чем неясные, хотя и страстные рассуждения о многих 
причинах Французской революции. Начальство готово согласиться с инжене- 
рами, что однозначные, простые вопросы изящно вписываются в электронные 
таблицы и проектные планы. 

Если бы реальный мир пошел таким же образом навстречу! К сожалению, 
если х сегодня равно 2, то завтра х может быть равно 5, а на следующей неде- 
ле — 3. Ведь ничто не вечно, и если вы сильно полагаетесь на какой-то факт, то 
можете быть уверены, что он все равно изменится. 

Реализовать что-нибудь можно всегда не одним, а несколькими способами. 
Кроме того, предоставить сторонний программный продукт может не один, а 
несколько поставщиков. Если вы вступаете в проект, недальновидно считая, что 
разработать его можно только одним способом, то будете неприятно удивлены. 
Многие проектные команды просто вынуждены пристально вглядываться в бу- 
дущее по мере разворачивания событий. И вот тому наглядный пример: 


“Но вы же сказали, чтобы мы пользовались базой данной ХҮ7! Мы за- 
программировали проект уже на 85%, и теперь уже нельзя ничего изме- 
нить! — запротестовал программист. 


— Извините, но наша компания решила перевести все наши проекты 
на базу данных РОО как на стандартную. И я не могу с этим ничего 
поделать. Нам просто придется перепрограммировать проект, а всем 
вам — работать и в выходные, впредь до особого распоряжения”. 


Изменения совсем не обязательно должны быть до такой степени коренными 
или даже немедленными. Но со временем, по мере развития проекта, вы можете 
оказаться в безвыходном положении, если с каждым очень важным решением 
проектная команда берет на себя обязательство достичь более мелкой цели, воп- 
лощающей суженную версию реально с меньшим числом вариантов выбора. 

И к тому времени, когда многие важные решения будут сделаны, цель ока- 
жется настолько мелкой, что вы непременно промахнетесь, если она сместится, 
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изменится направление ветра или японская бабочка махнет в Токио крылышка- 
ми. А промахнуться вы можете очень сильно. 

Все дело в том, что важные решения не так легко повернуть вспять. Как толь- 
ко вы решите воспользоваться базой данных конкретного поставщика, архитек- 
турным шаблоном или определенной моделью развертывания, тем самым вы 
возьмете на себя обязательство выполнить порядок действий, который нельзя 
отменить, разве что ценой немалых затрат. 


ОБРАТИМОСТЬ 


Многие темы в этой книге посвящены особенностям производства гибко- 
го, адаптируемого программного обеспечения. Если придерживаться приведен- 
ных в них рекомендаций, особенно принципа ОКУ, описанного ранее в разделе 
“Тема 9. ОКУ — пороки дублирования”, развязывания, обсуждаемого в разделе 
“Тема 28. Развязывание” главы 5, а также применения внешней конфигурации, 
как поясняется в разделе “Тема 32. Конфигурирование” главы 5, то не придет- 
ся принимать много важных решений, которые могут оказаться необратимыми. 
И это совсем неплохо, поскольку мы не всегда принимаем наилучшие решения с 
первого раза. Придерживаясь определенной технологии, мы лишь впоследствии 
обнаруживаем, что не можем нанять достаточно людей с требующимися навы- 
ками. Мы замыкаемся на определенном поставщике стороннего программного 
обеспечения, после чего его перекупает конкурент. Требования, пользователи и 
аппаратные средства меняются быстрее, чем нам удается разработать програм- 
мное обеспечение. 

Допустим, на ранней стадии работы над проектом вы решили воспользо- 
ваться базой данных от поставщика А. Гораздо позже, на стадии тестирования 
производительности, вы обнаруживаете, что выбранная вами база данных ра- 
ботает слишком медленно, тогда как документная база данных от поставщика В 
работает быстрее. Выходит, что вам просто не повезло, как это бывает в боль- 
шинстве обыкновенных проектов. Зачастую обращения к сторонним програм- 
мным продуктам глубоко вплетены в исходный код. Но если вы действительно 
обобщите саму идею базы данных, причем до такой степени, чтобы она просто 
предоставляла услуги хранения данных в качестве службы, то у вас появится 
удобная возможность поменять лошадей на переправе. 

Аналогично допустим, что ваш проект начинается как браузерное приложе- 
ние, но на более поздней его стадии в отделе сбыта решают, что им на самом 
деле требуется мобильное приложение. Насколько трудно вам будет перестро- 


М Попробуйте внести небольшое изменение в одно извходных воздействий нелинейной или 
хаотической системы. В итоге вы можете получить существенно иной и зачастую непред- 
сказуемый результат. Обыкновенная японская бабочка, машущая крылышками в Токио, 
может стать началом целой цепочки событий, которая закончится торнадо в штате Техас. 
Не напоминает ли это какой-нибудь известный вам проект? 
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иться по ходу дела? В идеальном случае это не должно особенно повлиять на 
ваш проект — по крайней мере, на его серверную сторону. Вам придется лишь 
удалить НТМГ-разметку воспроизведения, заменив ее соответствующим АРІ. 

Ошибка кроется в допущении, что любое решение принимается окончатель- 
но, а следовательно, в неготовности к непредвиденным обстоятельствам, кото- 
рые могут так или иначе возникнуть. Вместо того чтобы принимать решения 
бесповоротно, как высеченные на камне, рассматривайте их как начертанные 
на береговом песке. Ведь большая волна может нахлынуть в любой момент и 
смыть их без следа. 


Окончательных решений не существует 


ГИБКАЯ АРХИТЕКТУРА 


Несмотря на то что многие программисты стараются сохранять как можно 
более гибким сам код, необходимо также подумать и об удобстве сопровожде- 
ния на уровне архитектуры, развертывания и интеграции сторонних програм- 
мных продуктов. С начала нынешнего столетия и вплоть до момента написания 
этих строк появились следующие “нормы наилучшей практики” построения 
серверных архитектур. 


• Большая груда железа. 

• Образования больших груд железа. 

• Кластеры недорогого стандартного оборудования, выровненные по нагрузке. 
» Облачные виртуальные машины, выполняющие приложения. 

• Облачные виртуальные машины, выполняющие службы. 

• Контейнеризованные варианты облачных виртуальных машин. 

• Бессерверные приложения с облачной поддержкой. 


® И как неизбежность, вполне очевидный возврат к большим грудам железа 
для решения некоторых задач. 


Можете дополнить этот список самыми последними веяниями и благоговей- 
но считаться с ними как с каким-то чудом, благодаря которому что-то вообще 
работает. Можно ли вообще запланировать все это многообразие архитектур- 
ных решений? Никак нельзя. 

Единственное, что можно действительно сделать, — это упростить измене- 
ния. В частности, скрывайте сторонние АРІ за собственными уровнями абстрак- 
ции. Разбивайте свой код на компоненты, даже если их придется развертывать 
на одном крупном сервере. Ведь это намного проще, чем разбивать на части 
одно монолитное приложение. Мы убедились в этом на собственном горьком 
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опыте. Наконец, приведем еще один полезный совет, хотя он и не имеет непос- 
редственного отношения к рассматриваемому здесь вопросу обратимости. 


Остерегайтесь увлекаться новомодными веяниями 


Никто не знает, что сулит нам будущее! Поэтому заставляйте свой код “тряс- 
тись”, когда это возможно, и живо “крутиться”, когда это необходимо, как в тан- 
це рок-н-рол. 


Другие разделы, связанные с данной темой 


Ф 


Тема 8. Сущность качественного проектирования. 

Тема 10. Ортогональность. 

Тема 19. Контроль версий, глава 3 “Основные инструментальные средства". 
Тема 28. Развязывание, глава 5 “Гибкость или ломкость’. 

Тема 45. Западня требований, глава 8 “До начала проекта”. 


Тема 51. Начальный набор инструментальных средств программиста-праг- 
матика, глава 9 “Прагматичные проекты". 


Задачи 


А теперь уделите немного времени квантовой механике, проведя мыслен- 
ный эксперимент, называемый “котом Шрёдингера” Представьте, что вы 
закрыли кота в ящике с радиоактивной частицей, которая распадется на 
две другие частицы с вероятностью 50%. Если она распадется, то убьет 
кота, а если не распадется, то кот останется живым. Так погибнет кот или 
выживет? По мнению Шрёдингера, верно и то и другое — по крайне мере, 
до тех пор, пока ящик закрыт. Всякий раз, когда происходит субъядерная 
реакция с двумя возможными исходами, мир распадается на два других: 
один, где событие произошло, а другой, где оно не произошло. Кот выжи- 
вет в одном мире и погибнет в другом. И вы узнаете, в каком именно мире 
находитесь сами, лишь тогда, когда откроете ящик. 


Не удивительно, что программировать на будущее так трудно. 


Но подумайте об эволюции своего кода как о ящике, в котором полно ко- 
тов Шрёдингера, когда всякое решение может привести к разным версиям 
кода в будущем. Сколько возможных вариантов будущего развития спосо- 
бен поддерживать ваш код? Какие из них наиболее вероятны? Насколько 
трудно будет их поддерживать, когда настанет время? Отважитесь ли вы 
открыть ящик? 


ЕЕ О ИНА НЫ 
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ТРАССИРУЮЩИЕ ПУЛИ 


р 


“Заряжай! Огонь! Целься!... 


Неизвестный сержант 


При разработке программного обеспечения нередко речь заходит о попада- 
нии в цель. И хотя мы не стреляем по мишени на огневом рубеже, такая мета- 
фора все же оказывается очень удобной. В частности, любопытно выяснить, как 
попасть в цель в сложном и постоянно меняющемся мире. 

Ответ на этот вопрос, безусловно, зависит от характера того устройства, 
которое вы нацеливаете. И у вас лишь один шанс прицелиться и лишь затем 
убедиться, попали ли вы в яблочко, удовлетворив своего клиента. Но есть и 
лучший способ. 

Вам, вероятно, приходилось не раз видеть в кино, по телевизору или в видео- 
играх, как люди стреляют из пулеметов? В подобных сценах траектории полета 
пуль нередко наблюдаются как яркие полосы света в атмосфере. Такие полосы 
оставляют за собой трассирующие пули. 

Трассирующие пули устанавливаются в пулеметную ленту через определен- 
ные промежутки вместе с обычными боеприпасами. Когда они выстреливаются, 
содержащийся в них фосфор загорается, оставляя огненный след, тянущийся от 
пулемета к тому месту, куда они попадают. Если трассирующие пули попадут в 
цель, то в нее попадут и обычные пули. Солдаты делают очереди трассирующи- 
ми пулями для того, чтобы уточнить прицеливание, поскольку они дают вполне 
прагматичную, оперативную реакцию в условиях реальной стрельбы. 

Аналогичный принцип можно применить и к проектам, особенно в том слу- 
чае, если приходится проектировать нечто совершенно новое, не имея прежне- 
го опыта. Мы пользуемся термином разработка методом трассирующих пуль, 
чтобы наглядно показать потребность в немедленной реакции в действительных 
условиях с подвижной конечной целью. 

Проектируя совершенно новую систему, вы, подобно пулеметчикам, пытае- 
тесь попасть в цель, находясь в полной темноте. Ваши пользователи вообще не 
сталкивались прежде с такой системой, поэтому их требования не совсем ясны. 
А вам приходится решать уравнение со многими неизвестными, поскольку вы 
можете пользоваться незнакомыми прежде алгоритмами, методиками, языками 
или библиотеками. Для завершения подобных проектов требуется время, и по- 
этому можно смело предположить, что ваша рабочая среда изменится задолго 
до того, как вы завершите работу над своим проектом. 

Классический подход к проектированию системы состоит в том, чтобы со- 
ставить ее спецификацию во всех подробностях, исписав стопки бумаги, акку- 
ратно составив перечень всех требований, связав все неизвестные и наложив 
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ограничения на рабочую среду. При этом стрельба по конечной цели ведется 
с точным расчетом: сначала делается один крупный предварительный расчет, 
а затем производится выстрел с надеждой попасть в цель. Но программисты- 
прагматики предпочитают в подобных случаях пользоваться программным эк- 
вивалентом трассирующих пуль. 


Код, СВЕРКАЮЩИЙ В ТЕМНОТЕ 


Трассирующие пули удобны тем, что они действуют в тех же условиях и при 
тех же самых ограничениях, что и настоящие пули. Они быстро достигают цели, 
так что стрелок сразу же получает ответную реакцию. А с практической точки 
зрения они являются относительно недорогим решением. Чтобы добиться ана- 
логичного результата в коде, мы ищем нечто, быстро наглядно и неоднократно 
приводящее нас от исходного требования к некоторому свойству конечной сис- 
темы. 

Ищите сначала самые важные требования, определяющие систему, а затем те 
участки, где у вас имеются сомнения и где вы видите наибольшие риски. Рас- 
ставьте далее приоритеты в своей разработке, чтобы они указывали на те учас- 
тки, с которых следует в первую очередь начать программирование. 


Пользуйтесь методом трассирующих пуль для отыскания цели 


В действительности, принимая во внимание сложность организации проекта 
в современных условиях с массой внешних зависимостей и инструментальных 
средств, метод трассирующих пуль приобретает еще большее значение. Для раз- 
работчиков первая трассирующая пуля просто состоит в том, чтобы создать 
проект, добавить в него код, выводящий пробное сообщение типа “Здравствуй, 
мир!’ а затем убедиться, что этот код компилируется и выполняется. Далее сле- 
дует найти участки неопределенности во всем приложении и добавить скелет- 
ный вариант, требующийся для того, чтобы привести его в работоспособное 
состояние. 

Рассмотрим приведенную ниже диаграмму, где показаны пять архитектурных 
уровней проектируемой системы. Нас интересует, каким образом они интегри- 
руются, поэтому найдем простое функциональное средство, позволяющее испы- 
тать их вместе. Диагональная линия на этой диаграмме показывает путь, кото- 
рый некоторое функциональное средство проходит через исходный код. Чтобы 
воплотить все это в жизнь, достаточно реализовать окрашенные сплошным цве- 
том участки диаграммы на каждом уровне, тогда как все, что обозначено на ней 
завитками, будет реализовано в дальнейшем. 
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цлллл| Еще не реализовано 


Однажды нам пришлось вести сложный маркетинговый проект с базой дан- 
ных архитектуры “клиент-сервер”. Часть требований к данному проекту состоя- 
ла в предоставлении возможности составлять и выполнять временные запросы. 
На серверах был установлен целый ряд реляционных и специализированных 
баз данных, а клиентский пользовательский интерфейс был написан на произ- 
вольно выбранном языке А, в котором применялся ряд библиотек, написанных 
на другом языке для обеспечения интерфейса с серверами. Пользовательский 
запрос сохранялся на сервере в виде 1іѕр-подобной записи, прежде чем быть 
преобразованным в оптимизированный запрос 501 непосредственно перед его 
выполнением. В данном проекте было много неизвестных и самых разных сред, 
причем никто не знал точно, как должен себя вести пользовательский интер- 
фейс. 

Это была прекрасная возможность воспользоваться трассирующим кодом. 
С этой целью мы разработали каркас клиентской части системы, библиотеки для 
представления запросов и структуру для преобразования хранимых запросов в 
фактические запросы конкретной базы данных. Затем мы собрали все это вместе 
и проверили на работоспособность. И хотя мы могли направить в этом первона- 
чально собранном варианте лишь запрос, в котором перечислялись все строки в 
таблице базы данных, мы все же смогли убедиться, что пользовательский интер- 
фейс способен взаимодействовать с библиотеками, сами библиотеки — выпол- 
нять сериализацию и десериализацию запроса, а сервер — формировать запрос 
ЗОГ из полученного результата. В течение последующих месяцев мы постепенно 
наполнили деталями эту основную структуру, добавили новые функциональные 
возможности, параллельно нарастив каждый компонент трассирующего кода. 
По мере внедрения нового типа запроса в пользовательский интерфейс библио- 
тека разрасталась, а формирование запроса 501 усложнялось. 
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Трассирующий код пишется не для одноразового применения, а надолго. Он 
содержит все проверки ошибок, структурирование, документирование и само- 
проверку, как и любой фрагмент выходного кода. Он просто не полностью функ- 
ционален. Но как только будет достигнуто сквозное соединение компонентов 
вашей системы, вы сможете проверить, насколько близки вы к желанной цели, и 
вносить коррективы по мере надобности. Как только цель будет достигнута, до- 
бавить требующиеся функциональные возможности не составит особого труда. 

Разработка методом трассирующих пуль согласуется с представлением о том, 
что проект никогда не завершается. В нем всегда найдется место для изменений 
и добавлений новых функций. Это постепенный подход. Обычно его альтерна- 
тивой является тяжеловесный подход, при котором исходный код разбивается 
на модули, программируемые по отдельности. Эти модули затем объединяются 
в сборки, а те, в свою очередь, объединяются дальше до тех пор, пока однажды 
не получится готовое приложение. И лишь тогда приложение может быть пред- 
ставлено как единое целое пользователям для последующего тестирования. 

У подхода к разработке с помощью трассируемого кода имеются следующие 
преимущества. 


® Пользователи могут увидеть нечто работоспособное уже на ранней ста- 
дии разработки. Если вы своевременно известите пользователей о том, что 
вы делаете (см. раздел “Тема 52. Доставляйте своим пользователям удоволь- 
ствие” главы 9), они будут заранее знать, что увидят нечто еще не зрелое. 
Следовательно, их не разочарует нехватка функциональных возможностей, 
и они будут восторженно приветствовать видимый прогресс в разработке 
создаваемой для них системы. Они также смогут внести свой вклад в про- 
ект по ходу работы над ним, повысив тем самым свою заинтересованность 
в нем. Те же самые пользователи, вероятнее всего, подскажут вам, насколь- 
ко вы приблизились к желанной цели на каждом последующем шаге. 


® Разработчики создают структуру, чтобы работать в ней. Больше всего 
пугает пустой лист бумаги, на котором вообще ничего не написано. Если 
вы выяснили все сквозные взаимодействия в своем приложении и вопло- 
тили их в коде, то вашей команде не придется ничего особенного брать с 
потолка. Это способствует повышению общей производительности труда 
и согласованности действий в команде. 


® У вас есть платформа для интеграции. Как только вы осуществите сквоз- 
ное соединение компонентов системы, вы получите в свое распоряжение 
такую среду, в которую можно будет благополучно внедрить новые фраг- 
менты кода, как только они пройдут модульное тестирование. Вместо того 
чтобы пытаться интегрировать все одним махом, вы можете выполнять 
интеграцию каждый день, а то и несколько раз в день. В этом случае вли- 
яние каждого нового изменения становится более очевидным, тогда как 
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взаимодействия — более ограниченными, а следовательно, отладка и тес- 
тирование выполняются быстрее и точнее. 


® Вам есть что продемонстрировать. Спонсоры проекта и высшее началь- 
ство обычно требуют, чтобы им показали демонстрационные версии в са- 
мые неподходящие для этого моменты. Благодаря трассирующему коду у 
вас всегда будет что предъявить. 


» Вы лучше ощущаете прогресс. Работая над проектом методом трассирую- 
щих пуль, разработчики занимаются прецедентами использования по оче- 
реди. Справившись с одним прецедентом использования, они переходят к 
другому. Благодаря этому оказывается намного проще количественно оце- 
нить производительность и продемонстрировать пользователям прогресс 
в работе над проектом. А поскольку каждая индивидуальная разработка 
ведется в более мелких масштабах, то можно избежать создания монолит- 
ных блоков кода, о завершенности которых на 95% разработчики отчиты- 
ваются с недели на неделю. 


ТРАССИРУЮЩИЕ ПУЛИ НЕ ВСЕГДА ПОПАДАЮТ В ЦЕЛЬ 


Обычно трассирующие пули показывают, куда вы попали. Но это не всегда 
может быть желанная цель. В таком случае вам придется поправлять прицел до 
тех пор, пока вы не попадете точно в цель. И в этом основная идея трассирую- 
щих пуль. 

То же самое относится и к трассирующему коду. Вы пользуетесь данным ме- 
тодом в обстоятельствах, когда не знаете точно, куда движетесь. И поэтому не 
удивляйтесь, если, сделав две первые попытки, вы промахнетесь, а пользователь 
скажет: “Это совсем не то, что я имел в виду’, нужные вам данные окажутся не- 
доступны именно тогда, когда они вам потребуются, или же упадет производи- 
тельность. В таком случае измените результат, которого вы уже добились, чтобы 
перенести его поближе к цели, и будьте благодарны за то, что вы воспользова- 
лись данной методикой разработки. Ведь небольшой фрагмент кода обладает 
малой инертностью, так что его можно очень быстро и легко изменить. Помимо 
этого, вы сумеете собрать отзывы о своем приложении, а затем быстро и деше- 
во сгенерировать новую, более точную его версию. А поскольку все основные 
компоненты вашего приложения представлены в трассирующем коде, то поль- 
зователи могут быть уверены, что все, что они увидят, основывается на чем-то 
реальном, а не только на бумажной спецификации. | 


ТРАССИРУЮЩИЙ КОД В СРАВНЕНИИ С ПРОТОТИПИРОВАНИЕМ 


Можно решить, что рассматриваемый здесь метод трассирующего кода ока- 
зывается не более, чем прототипированием, только более воинственно назван- 
ным. Ведь с помощью прототипа вы нацеливаетесь на исследование конкретных 
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свойств конечной системы. А настоящий прототип помогает вам отбросить все, 
что вы связали вместе, когда опробовали какой-нибудь принцип, а затем пере- 
программировать, руководствуясь извлеченными вами уроками. 

Допустим, вы разрабатываете приложение, помогающее грузоотправителям 
выяснить, как упаковать ящики нестандартных размеров в контейнеры. Среди 
прочих трудностей, пользовательский интерфейс такого приложения должен 
быть интуитивным, тогда как алгоритмы, применяемые вами для определения 
оптимального варианта упаковки, довольно сложные. 

Вы могли бы, конечно, создать с помощью специального инструментального 
средства прототип пользовательского интерфейса для его демонстрации конеч- 
ному пользователю, а также запрограммировать его настолько, чтобы он реа- 
гировал на действия пользователя. И как только пользователь согласился бы с 
компоновкой прототипа, вы могли бы отбросить его и перепрограммировать 
пользовательский интерфейс — на этот раз уже с бизнес-логикой, используя це- 
левой язык. Аналогично вы могли бы прототипировать целый ряд алгоритмов, 
выполняющих конкретную задачу упаковки. Кроме того, вы могли бы написать 
функциональные тесты на таком неприхотливом языке высокого уровня, как, 
например, Рућоп, а тесты производительности на низком уровне — на каком- 
нибудь простом языке, близком к машинному. Но в любом случае, как только 
вы приняли бы решение, вам пришлось бы начинать все заново, программируя 
алгоритмы в среде их конечного применения, взаимодействующей с реальным 
миром. В этом, собственно, и состоит прототипирование, польза от которого 
несомненна. 

Метод трассирующего кода направлен на разрешение другого затруднения, 
когда вам требуется знать, насколько удачно все приложение связано вместе. 
Ведь пользователям вашего приложения нужно показать, каким образом про- 
исходит его взаимодействие с ними на практике, а разработчикам — предоста- 
вить скелетный вариант его архитектуры, который можно было бы наполнить 
конкретным кодом. В таком случае вы можете написать трассирующий код, со- 
стоящий из тривиальной реализации алгоритма упаковки контейнера (возмож- 
но, действующего по принципу “первым пришел, первым обслужен”), а также 
простой, но работоспособный пользовательский интерфейс. И как только вы 
скомпонуете вместе все компоненты своего приложения, то получите каркас, 
который можно показать как пользователям, так и разработчикам. Со временем 
вы дополните этот каркас новыми функциональными возможностями, заменив 
ими суррогатные процедуры. Но сам каркас останется нетронутым, а вы будете 
уверены, что система и дальше поведет себя таким же образом, как и по завер- 
шении первого трассирующего кода. 

Рассмотренное выше отличие настолько важно, что его стоит еще раз пов- 
торить. Прототипирование приводит к генерации одноразового кода. А трас- 
сирующий код — скудный, но завершенный, образующий скелетный вариант 
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конечной системы. Прототипирование можно рассматривать как своего рода 
разведку местности и добывание разведывательных данных, прежде чем будет 
выпущена первая трассирующая пуля. 


Другие разделы, связанные с данной темой 
® Тема 13. Прототипы и памятные записки. 


ә Тема 27. Не опережайте свет фар вашего автомобиля, глава 4 “Прагматич- 
ная паранойя”. 


® Тема 40. Рефакторинг, глава 7 “По ходу кодирования”. 
• Тема 49. Прагматичные команды, глава 9 “Прагматичные проекты”. 
® Тема 50. Кокосами не обойтись, глава 9 “Прагматичные проекты”. 


» Тема 51. Начальный набор инструментальных средств программиста-праг- 
матика, глава 9 “Прагматичные проекты”. 


® Тема 52. Доставляйте своим пользователям удовольствие, глава 9 “Праг- 
матичные проекты”. 


НОВО ЗВ В О АИТ АНОД СУУУ А длан МИ РАЛ НРУ О бо ОАО С О О И а о мым 


ПРОТОТИПЫ И ПАМЯТНЫЕ ЗАПИСКИ 


Прототипы применяются во многих отраслях промышленности для опробо- 
вания конкретных идей, ведь создавать прототипы намного дешевле, чем произ- 
водить полномасштабные образцы продукции. Например, автомобилестроители 
могут создавать самые разные прототипы новой конструкции, используя каж- 
дый из них для испытания конкретного свойства автомобиля: аэродинамики, 
стилевого оформления, конструктивных характеристик и т.д. А приверженцы 
старых традиций пользуются моделью из глины для испытаний в аэродинами- 
ческой трубе, тогда как для отдела дизайна может вполне подойти пробковое де- 
рево и клейкая лента. Менее романтичным выглядит моделирование на экране 
компьютерного монитора или в виртуальной реальности, хотя оно и обходит- 
ся намного дешевле. В последнем случае рискованные и ненадежные элементы 
конструкции можно испытать, не прибегая к построению настоящего образца. 

Мы создаем прототипы программ аналогичным образом и в тех же целях: 
чтобы проанализировать и выявить риск, а также дать возможность внести кор- 
рективы, существенно снизив затраты. Как и автомобилестроители, мы можем 
нацелить прототип на проверку одного или нескольких конкретных аспектов 
проекта. 

Мы привыкли считать, что прототипы основываются на коде, хотя это не 
всегда именно так. Как и автомобилестроители, мы можем построить прототи- 
пы из различных материалов. В частности, памятные записки на клейких лис- 
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точках бумаги как нельзя лучше подходят для прототипирования таких динами- 
ческих элементов, как рабочий поток и прикладная логика. А пользовательский 
интерфейс можно прототипировать в виде рисунка на белой доске или нефунк- 
ционального макета, нарисованного в программе раскраски или в конструкторе 
интерфейса. 

Прототипы служат для поиска ответов лишь на немногие вопросы, поэтому 
они обходятся намного дешевле и создаются быстрее, чем приложения, пере- 
даваемые в эксплуатацию. В коде прототипа можно пренебречь подробностя- 
ми, которые не важны в данный момент, но впоследствии могут стать очень 
важными для пользователей. Так, если создается прототип пользовательского 
интерфейса, в таком случае можно довольствоваться и неточными результата- 
ми или данными. А если исследуются вычислительные или производительные 
особенности приложения, то можно довольствоваться и весьма скромным поль- 
зовательским интерфейсом, а возможно, и вообще обойтись без него. 

Но если вы окажетесь в такой среде, где нельзя пренебречь подробностями, 
то спросите себя: а стоит ли вообще создавать прототип? В таком случае вам, 
может быть, больше подойдет разработка методом трассирующих пуль (см. 
выше раздел “Тема 12. Трассирующие пули”). 


Что ПОДЛЕЖИТ ПРОТОТИПИРОВАНИЮ 


Что можно выбрать для исследования с помощью прототипа? Все, что несет 
в себе риск, все, что еще не было опробовано, или то, что крайне важно для ко- 
нечной системы, а также все, что не проверено, экспериментально, сомнитель- 
но или то, в чем нет никакой уверенности. Итак, прототипированию подлежит 


следующее. 
® Архитектура. 
® Новые функциональные возможности уже имеющейся системы. 
® Структура или содержание внешних данных. 
® Сторонние инструментальные средства или компоненты. 
® Вопросы производительности. 


• Оформление пользовательского интерфейса. 


Прототипирование означает опыт познания. Его ценность состоит не в про- 
изводимом коде, а в извлекаемых уроках. И в этом заключается весь смысл про- 
тотипирования. 


Создавайте прототипы для обучения 


Тема 13 • Прототипы и памятные записки 91 


КАК ПОЛЬЗОВАТЬСЯ ПРОТОТИПАМИ 


Ниже перечислены подробности, которыми можно пренебречь, создавая 
прототипы. 


Ф Правильность. Там, где это уместно, возможно, удастся воспользоваться 
фиктивными данными. 


® Завершенность. Прототип может функционировать лишь в весьма огра- 
ниченном смысле, а возможно, и с единственным предварительно выбран- 
ным фрагментом входных данных и одним пунктом меню. 


® Надежность. Проверка ошибок вряд ли должна быть полной, а возмож- 
но, и вообще должна отсутствовать. Если отклониться от заранее опреде- 
ленного пути, прототип может потерпеть крах и сгореть ярким пламенем. 
И это нормально. 


® Стиль программирования. Исходный код прототипа вряд ли следует снаб- 
жать комментариями или документировать, хотя и можно написать целые 
стопки документации, опираясь на свой опыт работы с прототипом. 


В прототипах подробности не принимаются во внимание, которое сосредото- 
чено в основном на конкретных свойствах исследуемой системы, и поэтому про- 
тотипы можно реализовать на языке сценариев (например, Руіћоп или Кобу), 
который по своему уровню выше, чем другие языки, применяемые в остальной 
части проекта, поскольку они могут лишь стать помехой. Продолжить дальней- 
шую разработку можно как на языке, выбранном для создания прототипа, так 
и перейти на другой язык. Ведь в конечном итоге прототип все равно будет 
отброшен за ненадобностью. 

Для прототипирования пользовательского интерфейса можно воспользовать- 
ся инструментальным средством, позволяющим сосредоточиться на внешнем 
виде и/или взаимодействии интерфейса с пользователем, не особенно беспоко- 
ясь о коде или разметке. Языки сценариев вполне пригодны и в качестве связую- 
щего звена для объединения низкоуровневых фрагментов в новые комбинации. 
Применяя такой подход, можно очень быстро собрать существующие компонен- 
ты в новые конфигурации, чтобы проверить их на работоспособность. 


ПРОТОТИПИРОВАНИЕ АРХИТЕКТУРЫ 


Многие прототипы создаются для моделирования всей рассматриваемой сис- 
темы. В отличие от метода трассирующих пуль, индивидуальные модули совсем 
не обязательно должны как-то по-особому функционировать в прототипной 
системе. В действительности для прототипирования архитектуры можно даже 
не программировать, поскольку это можно сделать на белой доске, листках для 
памятных записок или карточках для записей. В данном случае требуется вы- 
яснить, каким образом система связана в единое целое, не обращая, опять же, 
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внимания на подробности. Ниже перечислен ряд конкретных вопросов, кото- 
рые требуется выяснить, рассматривая архитектурный прототип. 


ә Вполне ли определены и приемлемы области ответственности основных 
компонентов системы? 


® Вполне ли определены взаимодействия основных компонентов системы: 
® Сведено ли к минимуму связывание? 

® Можно ли выявить потенциальные источники дублирования? 

® Насколько приемлемы определения интерфейсов и ограничения? 


® Имеется ли у каждого модуля путь доступа к данным, которые требуются 
ему во время выполнения? Имеет ли каждый модуль доступ именно тогда, 
когда он требуется: 


Последний ряд вопросов приносит больше всего неожиданностей и самых 
ценных результатов из опыта прототипирования. 


КАК НЕ СЛЕДУЕТ ПОЛЬЗОВАТЬСЯ ПРОТОТИПАМИ 


Прежде чем приступить к любому прототипированию на основе кода, убеди- 
тесь, что все заинтересованные лица ясно отдают себе отчет, что вы собираетесь 
писать одноразовый код. Ведь прототипы могут быть обманчиво привлекатель- 
ны для тех людей, которые не знают, что это всего лишь прототипы. Поэтому вы 
должны очень ясно дать понять, что данный код одноразовый, незавершенный 
и непригодный для завершения. 

Кажущаяся завершенность демонстрируемого прототипа может легко ввести 
в заблуждение, а попечители проекта или руководство могут даже настаивать 
на развертывании прототипа (или его детища), если вы не дадите ясно понять, 
чего именно следует ожидать от него. Напомните им, что вы можете построить 
отличный прототип нового автомобиля из пробкового дерева и клейкой ленты, 
но поехать на нем в часы пик вряд ли удастся! 

Если вы остро ощущаете, что назначение прототипного кода в вашей среде 
или культуре может быть понято превратно, в таком случае вам лучше выбрать 
метод трассирующих пуль. В конечном счете у вас будет прочный каркас в ка- 
честве основания для последующей разработки. 

Надлежащим образом применяемые прототипы позволяют сэкономить не- 
мало времени, средств и трудов, выявляя и корректируя потенциальные проб- 
лемные места на ранней стадии цикла разработки, когда исправление ошибок 
делается просто и обходится недорого. 


Другие разделы, связанные с данной темой 


® Тема 12. Трассирующие пули. 
® Тема 14. Предметно-ориентированные языки. 
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• Тема 17. Игры в скорлупки, глава 3 “Основные инструментальные сред- 
» 
ства. 


® Тема 27. Не опережайте свет фар вашего автомобиля, глава 4 “Прагматич- 
ная паранойя’. 


е Тема 37. Прислушивайтесь к своим инстинктам, глава 7 “По ходу кодиро- 
> 
вания”. 


® Тема 45. Западня требований, глава 8 “До начала проекта”. 


® Тема 52. Доставляйте своим пользователям удовольствие, глава 9 “Праг- 
матичные проекты”. 


Упражнения 


3. В отделе сбыта предложили обсудить вместе с вами несколько вариантов 
оформления веб-страниц, в том числе карты ссылок, выбираемые щелчком 
кнопкой мыши для перехода на другие страницы, и т.д. Но они не могут 
выбрать модель для изображения на карте ссылок из нескольких вариантов: 
автомобиля, телефона и дома. У вас имеется список целевых страниц и их 
содержимого, и поэтому им хотелось бы посмотреть несколько прототипов. 
Кстати, вам на это дается 15 минут. Какими инструментальными средствами 
вы могли бы для этого воспользоваться? 


О О О В ЗЕ та О о УУЛ Н арт бул АЦТ Ф ТАСА уи јн НОА АДИР 


__ ПРЕДМЕТНО-ОРИЕНТИРОВАННЫЕ ЯЗЫКИ 


“Границы моего языка означают границы моего мира”. 
Людвиг Виттгенштейн? 
Языки программирования компьютеров оказывают влияние на то, как мы 
осмысливаем задачу и как понимаем общение. У каждого такого языка имеется 
перечень средств, означаемых специальными терминами вроде статической или 
динамической типизации, раннего или позднего связывания, функционально- 
го или объектно-ориентированного программирования, моделей наследования, 
примесей, макрокоманд, причем все они могут предложить или затруднить оп- 
ределенные решения. Выработка решения, принимая во внимание особеннос- 
ти программирования на языке С++, может привести к иным результатам, чем 
решение, основанное на мышлении в стиле языка НазКе|, и наоборот. Но в то 
же время и язык предметной области может предложить решение для програм- 
мирования, что, на наш взгляд, важнее. 


З [48 Мібрепѕќеіп — австрийский философ и логик ХХ века. — Примеч. пер. 
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Мы всегда пытаемся писать код, пользуясь словарем из прикладной области 
(см. раздел “Ведение словаря” главы 8 “До начала проекта”). Иногда програм- 
мисты-прагматики могут перейти на следующий уровень и сразу приступить к 
программированию, пользуясь словарем, синтаксисом и семантикой (т.е. язы- 
ком) предметной области. 


Программируйте близко к предметной области 


НЕКОТОРЫЕ ПРЕДМЕТНО-ОРИЕНТИРОВАННЫЕ ЯЗЫКИ 


Итак, рассмотрим несколько примеров, в которых было сделано именно то, 
что и рекомендуется в приведенном выше совете. 


А5рес 
К $рес — это библиотека для тестирования кода, написанного на языке ВиБу. 
Она вдохновила на создание версий большинства других современных языков. 
Тест в В5рес преследует цель отразить ожидаемое поведение проверяемого кода, 
как показано в приведенном ниже примере. 
аӢеѕсгіре Вом11па5соге ао 
1Е "Еоёаіѕ 12 1Е уои зсоге 3 Ғоџг іітеѕ" ао 
ѕсоге = Вом11па5соге .пем 
4.сімеѕ { ѕсоге.ада р1пз (3) } 
ехресії (ѕсоге.іоГга1) .їо ед (12) 


епа 
епа 


Сиситбег 

СиситЪЬег — это язык программирования `, позволяющий составлять тесты 
нейтральным способом. Для выполнения тестов используется версия Сиситбег, 
подходящая для применяемого языка. Чтобы поддерживать такой же синтаксис, 
как и у нейтрального языка, придется написать также конкретные сопоставите- 
ли, распознающие фразы и извлекающие параметры для тестов. Ниже приведен 
характерный тому пример. 


11 


Ееаёиге: Ѕсогіпд 
ВасКагочопа: 
Сіуеп ап етріу ѕсогесага 
Ѕсепагіо: Ром11па а 10% о# 35 
Сіуеп І іһгоми а 3 
Апа І (№гом а 3 
Апа І ёһгои а 3 
Апа І “һгои а 3 
Тһеп спе ѕсоге ѕһоц1а ре 12 


10 См. по адресу ВЕЕр5: //гзрес.1пЕо. 
И См. по адресу ВЕЕрз: //сиситрег.1о/. 
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Тесты составлены на языке СисипаЬег таким образом, чтобы их могли прочи- 
тать клиенты программного обеспечения (хотя такое очень редко происходит на 
практике; возможные причины этого поясняются в приведенной ниже врезке). 


ПОРАТИВНЕ 


Одна из причин, по которым классический подход “собирание требований, 
проектирование, программирование, выпуск” оказывается недейственным, 
состоит в том, что он зиждется на понятии о том, что требования извест- 
ны, хотя такое бывает редко. Корпоративные пользователи весьма смутно 
представляют, чего они хотят достичь, но им неизвестны, да и не важны 
подробности. И в этом отчасти состоит ценность разработчиков, поскольку 
они постигают внутренним чутьем намерения своих клиентов и воплощают 
их в коде. 


Следовательно, когда вы настоятельно просите корпоративного пользова- 
теля окончательно утвердить требования или согласовать их с рядом фун- 
кций Сиситбег, это все равно, что заставить его проверить правописание 
в сочинении, написанном на шумерском языке. Он внесет ряд случайных 
изменений в требования, чтобы не уронить свое лицо, и утвердит их, чтобы 
побыстрее выпроводить вас из своего учреждения. 


Лучше предоставьте корпоративным клиентам работоспособный код, чтобы 
они могли опробовать его на практике. Именно тогда и проявятся их реаль- 
ные потребности. 


Маршруты Рһоепіх 


Во многих каркасах веб-приложений имеется средство маршрутизации, пре- 
образующее входящие НТТР-запросы в функции их обработки в коде. Ниже 
приведен характерный тому пример из Рћоепіх!?. 


зсоре "/", Не1]оРНоеп1х до 
ріре ЕРгоцай :ргомзег # использовать стандартный стек браузера 


де "/", РадеСопіго11ег, :1паех 
гезоцгсе$ "/цѕегѕ", ОѕегСопёго11ег 
епа 


12 См. по адресу ПЕЕрз : / /рһоепіхЁгатемогк.огд/. 
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В данном примере запросы, начинающиеся со знака "/", должны пройти 
через ряд фильтров, пригодных для браузеров. Сам запрос ресурса "/" бу- 
дет обработан функцией іпаех () из модуля РадеСопіго11ег. А в модуле 
ОѕегѕСопіго11ег реализуются все функции, требующиеся для управления 
ресурсом, доступным по следующему ОКІ: /иѕегѕ. 


АпѕібІіе 


АпѕіЫе — это инструментальное средство!?, предназначенное для конфигу- 
рирования программного обеспечения, как правило, на целом ряде удаленных 
серверов. С этой целью оно читает предоставляемую ему спецификацию, а затем 
делает все необходимое, чтобы зеркально отобразить ее на них. Спецификация 
может быть написана на ҮАМІ!* — языке, предназначенном для построения 
структур данных из текстовых описаний. Так, в приведенном ниже примере 
обеспечивается установка веб-сервера пршх на удаленных серверах, его запуск 
по умолчанию, а также применение предоставляемого файла конфигурации. 


- паме: іпѕёа11 пдіпх 
арі: пате=паіпх ѕёаёе=1аёеѕі 


- пате: епзоге па1пх 15$ гиппіпа (апа епаб1е іі аі рооі) 
зегуісе: пате=подіпх ѕёаёсе=ѕіагіеа епар1еЯ=уеѕ 


- пате: игісе ёһе пдіпх сопЁід Е11е 
сепр1Іаёе: ѕгс=іепр1аёеѕ/подіпх.сопЁ.]2 деѕі= /еёс/пдіпх/подіпх.сопЁ 
посіу: 
— геѕіагї пдіпх 


ХАРАКТЕРИСТИКИ ПРЕДМЕТНО-ОРИЕНТИРОВАННЫХ ЯЗЫКОВ 


Рассмотрим приведенные выше примеры более подробно. В частности, при- 
меры теста КЅрес и марштрутизатора Рћоепіх написаны на их базовых языках 
(ВиБу и ЕЇіхіг). В них употребляется довольно замысловатый код, включающий 
в себя метапрограммирование и макрокоманды, но в конечном счете они ком- 
пилируются и выполняются как обычный код. 

Тесты Сиситфег и конфигурации АпѕіЫе написаны на их собственных язы- 
ках. В частности, тест Сиситђег преобразуется в выполняемый код или в струк- 
туру данных, тогда как спецификации АпѕіЫе всегда преобразуются в структуру 
данных, выполняемую непосредственно в Ап5іЫе. 

В итоге код теста К5рес и марштрутизатора РБоешх внедряется в выпол- 
няемый прикладной код в виде подлинных расширений его словаря. А тесты 
Сиситбђег и конфигурации АпѕіЫе читаются прикладным кодом и преобра- 


'3 См. по адресу ВЕЕрз: //м\ии .ап$1Ю1е.сов/. 
М См, по адресу ВЕЕрз: //уат1.ога/. 
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зуются в некоторую форму, пригодную для употребления в прикладном коде. 
Тест В$рес и маршрутизатор Рһоепіх можно назвать примерами внутренних 
предметно-ориентированных языков, тогда как тест Сисштфег и конфигурацию 
Ап Ые — примерами внешних предметно-ориентированных языков. 


КомпРОМИСС МЕЖДУ ВНУТРЕННИМИ И ВНЕШНИМИ 
ПРЕДМЕТНО-ОРИЕНТИРОВАННЫМИ ЯЗЫКАМИ 


В общем случае во внутреннем предметно-ориентированном языке могут 
выгодно использоваться средства его базового языка, поскольку создаваемый 
предметно-ориентированный язык обладает большими функциональными воз- 
можностями, которые даются даром. Например, для автоматического создания 
набора тестов КЅрес можно воспользоваться некоторым кодом ВиБу. В этом слу- 
чае можно проверить очки на промахи или попадания: 


аезсг1ре Вом11па5соге о 
(0..4) .еасһ Яо |ріпѕ | 
(1..20) .еасһ ао |+Һгоиѕ | 
агдеї = ріпѕ * ЕҺһгомѕ 


іб "Еоёа1з #{(ёагдеї)} 1Е уои зсоге #{ріпѕ)} #{їһгоиѕ)} ёітеѕ" ао 
зсоге = Вом11пабсоге .пем 
Пгомз.Е1тез { зсоге.ааа р1пз (ріпѕ) } 
ехресї (5соге.$офа1).ф$о еа (+агае*) 

епа 

епа 
епа 
епа 


В итоге было написано 100 тестов, так что оставшаяся часть дня свободна! 

Недостаток внутренних предметно-ориентированных языков заключается в 
необходимости привязываться к их синтаксису и семантике. И хотя некоторые 
языки данной категории проявляют в этом отношении замечательную гибкость, 
все равно приходится искать компромисс между языком, который требуется, 
и языком, который можно реализовать. И все, что в конечном счете будет до- 
стигнуто, должно быть по-прежнему согласовано с синтаксисом целевого языка. 
Языки с макрокомандами (например, ЕЈіхіг, С]оаге и Сгуѕќа1) предоставляют не- 
много больше удобств, но синтаксис все равно остается синтаксисом. 

На внешние предметно-ориентированные языки подобные ограничения 
не накладываются. Если имеется возможность написать синтаксический ана- 
лизатор для такого языка, то именно так и следует поступить. Иногда можно 
воспользоваться сторонним синтаксическим анализатором, как это сделано в 
АпѕіБе с помощью УАМГ, но и тогда приходится искать компромисс. 

Написание синтаксического анализатора, вероятнее всего, означает внедре- 
ние новых библиотек (а возможно, и инструментальных средств) в разрабаты- 
ваемое приложение. А ведь написать качественный синтаксический анализа- 
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тор — дело непростое. Но если отважиться, то можно поискать и применить 
подходящие генераторы синтаксических анализаторов (например, Біѕоп или 
АМТГК) или каркасы для синтаксического анализа (например, многочисленные 
реализации анализаторов РЕС — грамматики, разбирающей выражения). 

Наша рекомендация довольно проста: не тратить усилий больше, чем можно 
сэкономить. Написание предметно-ориентированного языка так или иначе уве- 
личивает затраты на проект, и поэтому необходимо убедиться, что они окупятся 
(потенциально — в долгосрочной перспективе). 

В общем, пользуйтесь по возможности готовыми внешними предметно-ори- 
ентированными языками (например, ҮАМІ, ]$ОМ или С$У), а иначе — поищите 
подходящий внутренний язык. Пользоваться внешними языками рекомендуется 
только в тех случаях, когда выбранный вами язык будет написан пользователя- 
ми вашего приложения. 


ВНУТРЕННИЙ ПРЕДМЕТНО-ОРИЕНТИРОВАННЫЙ ЯЗЫК ПОЧТИ ДАРОМ 


Наконец, если просачивание синтаксиса базового языка не имеет особо- 
го значения, можно прибегнуть к одной хитрости, чтобы создать внутренний 
предметно-ориентированный язык. В частности, вместо усердного метапрог- 
раммирования достаточно написать функции, выполняющие все необходимые 
действия. На самом деле нечто подобное делается в В$рес, как показано ниже. 


аӢеѕсгіре Вом11па5соге Яо 
і "іоёаїѕ 12 1Е уоц зсоге 3 Ғоцг ёітеѕ" ао 
ѕсоге = Вом11па5соге .пем 
4.їітеѕ { ѕсоге.ада ріпѕ (3) } 
ехресї (ѕсоге.іоїіа1) .їо еч (12) 
епа 
епа 


В приведенном выше фрагменте кода деѕсгіре, ії, ехресі, іои еч — это 
всего лишь методы языка ВиБу. И хотя в нем скрыт внутренний механизм пере- 
дачи объектов, это все же код. Более подробно этот вопрос рассматривается в 
последующих упражнениях. 


Другие разделы, связанные с данной темой 
е Тема 8. Сущность качественного проектирования. 
® Тема 13. Прототипы и памятные записки. 


® Тема 32. Конфигурирование, глава 5 “Гибкость или ломкость”. 


Задачи 


• Можно ли выразить какое-нибудь требование к вашему текущему проекту на 
предметно-ориентированном языке? И можно ли написать компилятор или 
транслятор, способный сгенерировать большую часть требующегося кода? 
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® Если вы решаете принять мини-языки как средство программирования 
поближе к предметной области, то тем самым признаете, что для их реали- 
зации придется приложить некоторые усилия. Можете ли вы найти пути 
для повторного применения в других проектах того каркаса, который раз- 
рабатываете в текущем проекте? 


Упражнения 


4. 


Требуется реализовать мини-язык для управления простой системой чере- 
пашьей графики. Такой язык должен состоять из однобуквенных команд и 
одиночных цифр, указываемых после некоторых из них. В качестве примера 
применения такого языка ниже приведены входные команды для рисования 
прямоугольника. 


2 # выбрать перо 2 

# опустить перо 

# нарисовать линию длиной 2 см в западном направлении 

# затем нарисовать линию длиной 2 см в северном направлении 
# далее нарисовать линию длиной 2 см в восточном направлении 
# и, наконец, провести линию обратно в южном направлении 
# поднять перо 


ао ион 
новым 


Напишите код, реализующий синтаксический анализ команд этого мини- 
языка. Он должен быть разработан таким образом, чтобы вводить новые 
команды было просто. 


В предыдущем упражнении вам было предложено реализовать синтаксичес- 
кий анализатор для языка рисования, и это был внешний предметно-ориен- 
тированный язык. Теперь реализуйте его снова, но для внутреннего языка. 
Постарайтесь не делать ничего заумного, а просто напишите функцию для 
синтаксического анализа каждой команды. Вполне возможно, что вам при- 
дется изменить имена команд, обозначив их строчными буквами, а может 
быть, и заключить их в какую-нибудь оболочку, чтобы предоставить опре- 
деленный контекст. 


Разработайте грамматику ВМЕ (запись Бэкуса-Наура) для синтаксического 
анализа формата времени. Для такого анализа должны быть приемлемы все 
приведенные примеры формата времени. 


4рт, 7:38рт, 23:42, 3:16, 3:16атм 


Реализуйте на избранном вами языке синтаксический анализатор для грам- 
матики ВМЕ из предыдущего упражнения, используя генератор анализаторов 
РЕС. Такой анализатор должен выводить целое число, обозначающее коли- 
чество минут, прошедших после полуночи. 


Реализуйте синтаксический анализатор формата времени, используя язык 
сценариев и регулярные выражения. 


оаа С О А ОВ а а 
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ОцЕНИВАНИЕ 


В Библиотеке Конгресса США в Вашингтоне хранится около 75 терабайт 
цифровой информации, доступной в оперативном режиме. Любопытно, сколь- 
ко времени потребуется, чтобы переслать всю эту информацию по сети на ско- 
рости 1 Гбит/с? А сколько памяти потребуется для хранения миллиона Ф.И.О. 
и адресов? Сколько времени отнимет уплотнение 100 Мбайт текста? Наконец, 
сколько месяцев вам потребуется, чтобы выпустить свой проект? Отвечайте, 
живо! 

В какой-то степени все эти вопросы бессмысленны, поскольку они содержат 
недостаточно информации. И тем не менее на все эти вопросы вы можете найти 
ответы, если умеете выполнять оценки. Более того, в процессе оценивания вы 
сможете лучше понять среду, в которой обитают ваши программы. 

Научившись оценивать и развивать в себе этот навык до такой степени, что- 
бы чувствовать величины оцениваемых вещей, вы сможете проявить кажущу- 
юся, на первый взгляд, волшебной способность определять их осуществимость. 
Так, если кто-нибудь скажет: “Мы отправим резервную копию по сетевому со- 
единению в центральное хранилище”, вы должны быть в состоянии интуитивно 
почувствовать, насколько это практично. А когда вы программируете, вы долж- 
ны понимать, какой именно системе требуется оптимизация и какие системы 
можно оставить в покое. 


Выполняйте оценку, чтобы исключить неожиданности 


В качестве поощрения приведем в конце этого раздела единственно правиль- 
ный ответ, который следует дать, если вас попросят что-нибудь оценить. 


КАКОЙ ТОЧНОСТИ ОЦЕНКИ ДОСТАТОЧНО? 


Все ответы являются в той или иной мере оценками. Просто одни из них 
более точные, чем другие. Поэтому первый вопрос, который вы должны выяс- 
нить, когда вас попросят оценить что-нибудь, связан с контекстом, в котором 
вы должны дать свою оценку. В частности, требуется ли оценка с большой точ- 
ностью, или просящего о ней вполне удовлетворит приблизительное значение? 

Оценивание любопытно, в частности, тем, что интерпретация его результатов 
зависит от выбранных единиц измерения. Так, если вы скажете, что на какой- 
нибудь проект потребуется около 130 рабочих дней, то можно вполне предпо- 
ложить, что такая оценка достаточно точная. Но если вы скажете, что для этого 
потребуется около шести месяцев, то такая оценка будет воспринята как весь- 
ма приблизительная — в пределах от пяти до семи месяцев. Обе упомянутые 
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числовые оценки обозначают один и тот же срок, но первая из них, вероятно, 
подразумевает большую точность, чем вы считаете. Поэтому мы рекомендуем 
пользоваться приведенной ниже шкалой временных оценок. 


Продолжительность Оценка (порядок величин) 

1-15 дней Дни 

3-6 недель Недели 

8-20 недель Месяцы 

20 и больше недель Прежде чем оценивать, стоит хорошенько подумать 


Итак, если вы, проделав всю необходимую работу, решите, что выполнение 
проекта отнимет 125 рабочих дней (25 недель), то вам придется дать оценку 
“около шести месяцев” По тому же принципу оцениваются любые другие вели- 
чины: выберите единицы измерения, отражающие точность, с которой вы на- 
мерены дать свою оценку. 


ОТКУДА БЕРУТСЯ ОЦЕНКИ 


Все оценки основываются на моделях решаемой задачи. Но прежде чем пе- 
рейти к подробному описанию методов построения таких моделей, следует 
упомянуть простой прием оценивания, всегда дающий хорошие результаты: 
спросите того, кто уже это делал. Следовательно, прежде чем строить модель, 
поищите того, кто уже бывал в подобном положении, и выясните, как он решил 
свою задачу. Вы вряд ли найдете решение, точно соответствующее вашей задаче, 
но будете удивлены, как часто вы сможете обращаться к чужому опыту. 


Понимание того, что спрашивается 


Первая часть любого упражнения в оценивании состоит в понимании того, 
о чем именно спрашивают. Помимо рассмотренных выше вопросов, необходи- 
мо уяснить пределы предметной области. Нередко это подразумевается в самом 
вопросе, но необходимо выработать в себе привычку обдумывать пределы, пре- 
жде чем строить догадки. Зачастую выбранные пределы составляют часть отве- 
та, например: “Если не произойдет никаких дорожных происшествий и топлива 
в автомобиле окажется достаточно, я должен добраться до места за 20 минут”. 


Построение модели системы 


Это самая любопытная часть оценивания. Понимая то, о чем спрашивают, 
можно приступить к построению приближенной элементарной модели. Так, если 
вы оцениваете время реакции системы, ваша модель может включать в себя сер- 
вер и определенного рода входящий трафик. Для проекта моделью могут стать 
те стадии разработки, которые принято использовать в вашей организации, а 
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также весьма приблизительное общее представление о том, каким образом сис- 
тема может быть реализована. 

Построение модели может стать как творческим, так и полезным в долго- 
срочной перспективе процессом. Нередко процесс построения модели приво- 
дит к открытиям подспудных шаблонов и процессов, которые не были видны 
на поверхности. Возможно, даже придется проанализировать первоначальный 
вопрос заново, например: “Вы просили оценить компонент Х. Но похоже, что 
компонент У как вариант компонента Х можно сделать в два раза быстрее, по- 
теряв лишь одно свойство”. 

Построение модели вносит неточности в процесс оценивания, и это неиз- 
бежно, хотя и приносит известную пользу. Вам приходится искать компромисс 
между простотой и точностью модели. Так, удвоив усилия для проработки мо- 
дели, можно добиться лишь незначительного повышения ее точности. И здесь 
опыт должен подсказать вам, когда следует остановиться, уточняя модель. 


Разделение модели на компоненты 


Как только модель будет построена, ее можно разделить на компоненты. 
Для этого придется обнаружить математические правила, описывающие вза- 
имодействие компонентов. Иногда компонент привносит единственное значе- 
ние, добавляемое к конечному результату. Одни компоненты могут привносить 
множественные факторы, тогда как другие могут быть более сложными, как, 
например, те, которые имитируют поступление трафика в узел сети. Как прави- 
ло, у каждого компонента имеются свои параметры, оказывающие влияние на 
его участие в общей модели. В таком случае на данной стадии следует просто 
определить каждый параметр. 


Присваивание значения каждому параметру 


Как только будут определены все параметры, можно пройтись по ним, при- 
своив каждому соответствующее значение. На этом этапе можно ожидать вне- 
сения некоторого количества ошибок, поэтому следует выбрать те параметры, 
которые оказывают наибольшее влияние на конечный результат, и сосредо- 
точить все внимание на том, чтобы они получили правильные значения. Как 
правило, те параметры, значения которых добавляются к конечному результату, 
менее важны, чем те, значения которых умножаются или делятся. Так, удвоение 
скорости передачи данных в канале связи может привести к удвоению объема 
данных, принимаемых в час, тогда как добавление транзитной задержки на 5 мс 
не окажет заметного влияния. 

Для расчета этих очень важных параметров следует иметь вполне обосно- 
ванный способ. Например, для оценивания проектируемой системы массового 
обслуживания, возможно, придется измерить фактическую частоту поступле- 
ния транзакций в существующей системе или же найти аналогичную систему, 
чтобы измерить данный параметр. Аналогично можно измерить текущее время 
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обслуживания запроса или же оценить его, используя методы, описываемые в 
этом разделе. В действительности свои оценки нередко приходится основывать 
на других подоценках. Именно здесь и вкрадываются самые крупные ошибки. 


Вычисление ответов 


Лишь в самых простых случаях оценивание дает единственный ответ. Так, 
вы можете, не моргнув глазом, заявить, что способны пройти пять городских 
кварталов за 15 минут. Но по мере усложнения систем вам, вероятно, придется 
давать более осторожные ответы. Проведите многократные вычисления, варьи- 
руя значения самых важных параметров до тех пор, пока не получите такие зна- 
чения, которые действительно приводят модель в действие. И здесь неоценимую 
помощь могут оказать электронные таблицы. Затем сформулируйте свой ответ, 
исходя из этих параметров, например: “Время реакции составляет приблизитель- 
но три четверти секунды, если в системе применяются твердотельные накопите- 
ли и оперативная память объемом 32 Гбайт, и одну секунду, если объем памяти 
16 Гбайт” (Обратите внимание, насколько иное ощущение точности вызывает 
формулировка “три четверти секунды” по сравнению с обозначением 750 мс.) 

На стадии вычисления вы можете получить ответы, которые покажутся вам 
странными, но не спешите их отвергать. Если ваши арифметические расчеты 
правильны, вероятно, вы неверно понимаете стоящую перед вами задачу; воз- 
можно также, что неверна ваша модель. И это весьма ценная информация для 
оценивания. 


Прослеживание своих способностей оценивать 


Мы считаем, что вам стоит вести учет своих оценок, чтобы иметь возмож- 
ность выяснить, насколько они точны. Так, если для общей оценки требуется 
вычислить подоценки, проследите и их. Зачастую оценки будут казаться вам 
довольно хорошими, и со временем они, действительно, станут такими, как вы 
ожидали. 

Если оценка окажется неверной, не отмахивайтесь от нее и не уходите от от- 
вета, а лучше найдите причину. Вполне возможно, что вы выбрали такие пара- 
метры, которые не соответствуют действительности решаемой задачи, а может 
быть, ваша модель оказалась неверной. Какова бы ни была причина, уделите 
время, чтобы разобраться в произошедшем. И тогда следующая оценка окажется 
лучше. 


ОЦЕНИВАНИЕ СРОКОВ ВЫПОЛНЕНИЯ ПРОЕКТОВ 


Как правило, вас могут попросить оценить, сколько времени отнимет работа 
над чем-то конкретным. И если это нечто сложное, дать ему оценку, возможно, 
будет нелегко. В этом разделе мы рассмотрим два метода, позволяющих умень- 
шить неопределенность, проявляющуюся в подобных случаях. 
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Покраска ракеты 
— Сколько времени потребуется, чтобы покрасить дом? 


— Ну, если все будет нормально и расход этой краски окажется таким, 
как заявлено производителем, то может потребоваться не меньше 10 
часов, хотя это маловероятно. Думаю, что более реалистичная оценка 
ближе к 18 часам. И, конечно, если погода испортится, то работа мо- 
жет растянуться до 30 часов, а то и больше. 


Именно таким образом люди обычно оценивают окружающую их реальность, 
т.е. целым рядом возможных вариантов, а не одним числом, если только не при- 
нудить их дать именно такую оценку. Когда ВМС США потребовалось сплани- 
ровать проект баллистической ракеты “Поларис” для атомных подводных лодок, 
был принят именно такой порядок оценивания по так называемой методологии 
РЕКТ (Ргоргат Еуајиабіоп апа Кеуіеум Тесһпідие — Метод оценки и анализа про- 
ектов). По методологии РЕКТ каждая задача получает оптимистическую, наибо- 
лее вероятную и пессимистическую оценки. Все задачи организованы в граф за- 
висимостей, а для выявления самых оптимистичных и пессимистичных сроков 
выполнения работ во всем проекте используется простая статистика. 

Используя такую область значений, удается благополучно избежать самой 
распространенной причины ошибок при оценивании: раздувания цифр из-за 
неуверенности. Вместо этого статистика по методологии РЕКТ распределяет не- 
определенность автоматически, позволяя точнее оценить проект в целом. 

Тем не менее мы не являемся страстными поклонниками такой методологии. 
Ведь разработчики привыкли рисовать едва ли не на всю стену диаграммы всех 
задач в проекте, неявно полагая, что имеют его точную оценку просто потому, 
что они воспользовались какой-то формулой. И если они никогда не делали это- 
го прежде, то, скорее всего, точную оценку они не получат. 


Поедание слона 


Мы считаем, что составить календарный план проекта можно лишь на осно- 
вании опыта работы над тем же самым проектом. И в этом не будет никакого 
парадокса, если практиковать поэтапную разработку, повторяя шаги перечис- 
ленной ниже процедуры, на которых функциональные возможности внедряются 
очень тонкими слоями. 


® Проверить требования. 
$ Проанализировать риски (начав с самых рискованных элементов). 
® Спроектировать, реализовать, интегрировать. 


® Проверить правильность с помощью пользователей. 


Поначалу у вас может сложиться лишь смутное представление, сколько раз 
придется повторить данную процедуру и как долго это может продолжаться. 


Тема 15 = Оценивание 105 


И хотя некоторые методы требуют закрепить ее как часть первоначального пла- 
на, на самом деле это будет ошибкой во всех проектах, кроме самых тривиаль- 
ных. Ведь вам придется просто гадать, если только вы не разрабатывали прежде 
аналогичное приложение с той же самой командой. 

Итак, завершив кодирование и тестирование первоначальных функциональ- 
ных возможностей, отметьте это как окончание первого шага повторяющейся 
процедуры. Основываясь на приобретенном опыте, вы сможете теперь уточнить 
первоначальное предположение о количестве последующих шагов и о том, что 
следует включить в каждый из них. С каждым разом уточнение становится все 
лучше и вместе с тем растет уверенность в правильности графика выполнения 
работ. Такого рода оценивание нередко выполняется во время подведения ко- 
мандой итогов в конце повторяющегося цикла. И это еще раз подтверждает ста- 
рую шутку: слона нужно есть по кусочкам. 


Повторно уточняйте график выполнения работ 
по мере написания кода 


Такой метод оценивания может и не найти признания у руководства, ко- 
торому, как правило, требуется точное число еще до начала проекта. Поэтому 
вы должны объяснить руководству, что именно состав команды, ее произво- 
дительность и среда будут определять график выполнения работ. Формализуя 
это положение и уточняя график на каждом шаге повторяющейся процедуры, 
вы сумеете дать руководству самую точную оценку планирования работ, какую 
только сможете. 


Что ОТВЕТИТЬ НА ПРОСЬБУ ЧТО-НИБУДЬ ОЦЕНИТЬ 


На это следует ответить: “Вернемся к этому позже”. Если вы замедлите про- 
цесс, уделив время прохождению всех шагов описанной выше процедуры, то 
почти всегда сможете добиться лучших результатов. А оценки, данные мимохо- 
дом за чашкой кофе, будут еще не раз навещать и тревожить вас. 

Другие разделы, связанные с данной темой 
• Тема 7. Общайтесь!, глава 1 “Философия прагматизма”. 


ә Тема 39. Быстродействие алгоритма, глава 7 “По ходу кодирования". 


Задачи 


• Начните вести журнал своих оценок. Проследите за тем, насколько точной 
оказалась каждая из них. Если допущенная вами ошибка превысила 50%, 
постарайтесь выяснить, в чем именно она оказалась неверной. 
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Упражнения 


9. Представьте, что к вам обратились со следующим вопросом: “Чья пропуск- 
ная способность выше: сетевого соединения на скорости 1 Гбит/с или че- 
ловека, перемещающегося между двумя компьютерами с запоминающим 
устройством емкостью 1 Тбайт в своем кармане?” Какие ограничения вы 
наложите на свой ответ, чтобы дать его в правильных пределах? (Вы може- 
те, например, сказать, что временем доступа к запоминающему устройству 
можно пренебречь.) 


10. Так чья же пропускная способность выше? 


ГЛАВА 3 


Основные 
__ ИНСТРУМЕНТАЛЬНЫЕ СРЕДСТВА 


Каждый мастер начинает свое ремесло с основного набора качественных ин- 
струментов. В частности, столяру могут потребоваться линейки, уровни, пилы, 
качественные рубанки, тонкие долота, сверла и скрепы, киянки и струбцины. 
Эти инструменты тщательно подбираются, чтобы служить долго для выполне- 
ния особых работ вместе с другими инструментами, а самое, возможно, глав- 
ное — чтобы столяру было удобно работать с ними, держа их в своих пока еще 
неумелых руках. 

Затем начинается процесс обучения работе с инструментами и приспосаб- 
ливания к ним. Ведь у каждого инструмента свои свойства и особенности, а 
следовательно, он требует особого обращения. Каждый инструмент нужно по- 
особому заточить и соответственно держать в руках. Со временем все инстру- 
менты изнашиваются, вплоть до того, что их рукоятка напоминает отпечаток 
руки столяра, а режущая кромка идеально совпадает с углом, под которым он 
держит свой инструмент. И в этот момент инструменты превращаются в про- 
водников замыслов, возникающих в уме мастера, доводя их до готового изделия 
и становясь как бы продолжением его рук. Постепенно столяр пополняет свой 
арсенал новыми инструментами, в том числе ламельными фрезерными станка- 
ми, торцовочными пилами с лазерным наведением, шаблонами под “ласточкин 
хвост” и прочими чудесами техники деревообработки. Но можно не сомневать- 
ся, что столяру будет намного приятнее работать с одним из своих первых ин- 
струментов, держа его в руках и чувствуя, например, как рубанок буквально 
поет, скользя по дереву. 

Инструменты развивают ваши способности. Чем они лучше, и чем лучше вы 
знаете, как ими пользоваться, тем выше может стать производительность ваше- 
го труда. Начните с простого набора инструментальных средств, подходящих в 
общем случае. По мере обретения опыта обращения с ними и появления каких- 
то особых требований вы будете постепенно пополнять этот простой набор но- 
выми средствами. Как и любому другому мастеру, вам придется делать это регу- 
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лярно, поэтому старайтесь всегда искать лучшие способы делать свое дело. Если 
же возникнет ситуация, с которой текущие инструментальные средства, на ваш 
взгляд, не справятся, сделайте себе заметку, чтобы поискать какое-нибудь дру- 
гое или более эффективное инструментальное средство, которое поможет вам 
справиться с данной ситуацией. Пусть вашими приобретениями правит нужда. 

Многие начинающие программисты совершают ошибку, останавливая свой 
выбор лишь на одном эффективном инструментальном средстве (например, на 
конкретной интегрированной среде разработки), так и не покидая его удобный 
интерфейс. А вы должны чувствовать себя уверенно и за пределами конкрет- 
ной интегрированной среды разработки. И достичь этого можно единственным 
способом, храня свой набор простых инструментальных средств в постоянной 
готовности к применению. 

В этой главе речь пойдет об инвестировании в собственный набор простых 
инструментальных средств. Как и любое грамотное обсуждение инструменталь- 
ных средств, мы начнем (в следующем разделе) с рассмотрения исходных мате- 
риалов, которые требуется облечь в нужную форму. А далее мы перейдем к вер- 
стаку (в нашем случае — к компьютеру), чтобы выяснить, как пользоваться им, 
чтобы извлечь наибольшую пользу из инструментальных средств. Подробнее об 
этом — в разделе “Игры в скорлупки”. И как только в нашем распоряжении ока- 
жется сырьевой материал и станок для его обработки, мы обратимся к одному 
из наиболее употребительных инструментов (в данном случае — к текстовому 
редактору). Так, в разделе “Эффективное редактирование” предлагаются спосо- 
бы, повышающие эффективность труда программиста. 

Чтобы не утратить ничего из своей ценной работы, мы должны всегда поль- 
зоваться системой контроля версий — даже для таких личных документов, как 
рецепты или заметки. А поскольку Мерфи был все же оптимистом, несмотря на 
сформулированные им пессимистические законы, то нельзя стать грамотным 
программистом до тех пор, пока не приобретешь превосходные навыки отладки 
исходного кода. 

Чтобы скрепить все чудесное вместе, потребуется нечто вроде клея. Некото- 
рые возможности добиться этого рассматриваются в разделе “Манипулирование 
текстом”. Наконец, самые бледные чернила лучше, чем самая хорошая память. 
Поэтому ведите учет своих мыслей и предыстории, как поясняется в разделе 
“Технические дневники”. 

Уделяя время изучению всех упомянутых выше инструментальных средств, 
вы однажды с удивлением обнаружите, как ваши пальцы перемещаются по кла- 
виатуре, безотчетно манипулируя текстом. И это будет означать, что применяе- 
мые вами инструменты стали продолжением ваших рук. 
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СИЛА ПРОСТОГО ТЕКСТА 


Будучи программистами-прагматиками, мы выбираем в качестве исходного 
материала не дерево и не железо, а знания. Сначала мы собираем требования 
как знания, а затем выражаем эти знания в своих проектных решениях, реа- 
лизациях, тестах и документах. И мы считаем, что наилучшим форматом для 
постоянного хранения данных является простой текст. Благодаря простому 
тексту мы получаем возможность манипулировать знаниями как вручную, так и 
программно, пользуясь буквально каждым инструментальным средством, име- 
ющимся в нашем распоряжении. 

Но трудности обращения с большинством бинарных форматов состоят в том, 
что контекст, требующийся для понимания данных, отделен от самих данных, 
и тогда они искусственно отторгаются от своего смыслового значения. Кроме 
того, данные могут быть зашифрованы, и поэтому анализировать их без при- 
кладной логики совершенно бессмысленно. Тем не менее простой текст дает 
возможность получить поток самостоятельно описываемых данных независимо 
от того приложения, в котором он создан. 


Что ТАКОЕ ПРОСТОЙ ТЕКСТ 


Простой текст состоит из печатных символов в форме, передающей ин- 
формацию. Это может быть, например, простой список покупок, аналогичный 
приведенному ниже, или же сложный текст, подобный рукописи данной книги. 
(Она действительно набрана простым текстом к явному неудовольствию издате- 
ля, которому хотелось бы, чтобы мы пользовались для этого специализирован- 
ным текстовым редактором.) 

* молоко 

* сахар 

* кофе 

И здесь важна информационная часть. Так, следующая строка простого тек- 
ста вряд ли принесет какую-то пользу: 


11); 91)п РЕ)хгксЕеУВ )Кп1'р1обр7аа;уН рјхгаібгадуһј 
Как, впрочем, и эта строка: 
Е1е1а19=467аре 


Ведь читающий ее понятия не имеет, в чем смысл значения 467аре. Поэтому 
мы стараемся сделать набираемый нами простой текст удобочитаемым. 


Храните свои знания в виде простого текста 
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В ЧЕМ СИЛА ПРОСТОГО ТЕКСТА 


Простой текст совсем не означает, что сам он не структурирован. НТМГ, 
ЗОМ, ҮАМІ и все аналогичные форматы служат примерами простого текста, 
как, впрочем, и большинство основных сетевых протоколов, в том числе НТТР, 
5МТР, ІМАР и т.д. И для этого имеется ряд веских оснований, включая следу- 
ющие. 


$ Гарантия от устаревания. 
® Эффективное использование инструментальных средств. 


» Упрощение тестирования. 


Гарантия от устаревания 


Удобочитаемые формы данных и описывающие сами себя данные, несомнен- 
но, переживут все остальные формы данных и те приложения, в которых они 
сформированы. А раз они уцелеют, то есть шанс воспользоваться ими даже че- 
рез много времени после того, как перестанет функционировать первоначальная 
версия приложения, в котором они были сформированы. Такого рода файл дан- 
ных можно проанализировать, зная лишь частично его формат. Что же касается 
большинства бинарных файлов, то для успешного их анализа необходимо знать 
во всех подробностях их формат. 

Рассмотрим в качестве примера файл данных из устаревшей системы’, кото- 
рую вам дали сопровождать. Исходно вам мало что известно об ее первоначаль- 
ной версии, помимо того, что в ней ведется список номеров социального обес- 
печения клиентов, который требуется найти и извлечь. Среди прочих данных вы 
обнаруживаете следующее: 


<ЕТЕГО10>123-45-6789</ЕТЕГ,о10> 
<ЕІЕ1010>567-89-0123</ЕІЕІр10> 


<Е1Е1010>901-23-4567</ЕІЕІр10> 


Распознав формат номера социального обеспечения, вы можете быстро на- 
писать небольшую программу для извлечения данных из файла, даже если вам 
больше ничего не известно о другом его содержимом. 

Но представьте, что файл отформатирован иначе — например, так, как по- 
казано ниже. 


АС27123456789В11Р 
ХҮ435678901230ТҮТІ 


672190123456788АМ 


: Все программное обеспечение устаревает в момент его написания. 
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Вполне возможно, что вам не удастся легко распознать смысловое значение 
приведенных выше чисел. В этом, собственно, и состоит отличие удобочитае- 
мого содержимого файлов от неудобочитаемого. Тем не менее содержимое поля 
ЕІЕ1010 в рассматриваемом здесь файле мало чем помогает уяснить его смыс- 
ловое значение. А вот приведенный ниже формат делает его намного более по- 
нятным, гарантируя, что такие данные переживут тот проект, в котором они 
сформированы. 


<бОСТАГ-ЗЕСОВТТУ-М№О>123-45-6789</5ОСТАТ-ЗЕСОВТТУ-МО> 


Эффективное использование инструментальных средств 


Буквально каждое инструментальное средство в области вычислений (от сис- 
темы контроля версий до утилит командной строки) может оперировать простым 
текстом. Допустим, вы развертываете крупное приложение в условиях его эксплу- 
атации с помощью специального файла конфигурации. Если этот файл содержит 
простой текст, вы можете заменить его в системе контроля версий (см. далее раз- 
дел “Тема 19. Контроль версий”), чтобы автоматически отслеживать предысторию 
всех изменений. С помощью таких средств сравнения файлов, как, например, ути- 
литы 91 ЕЁ и Ес, вы можете сразу выяснить, какие именно изменения были вне- 
сены, тогда как утилита зим поможет сформировать контрольную сумму, чтобы 
проверить файл на предмет случайной (или злонамеренной) модификации. 


Как известно, операционная система Опіх спроектирована по принципу 
утилит — небольших заточенных инструментов, каждый из которых пред- 
назначен для выполнения одной конкретной операции. Этот основной при- 
нцип позволяет использовать общий базовый формат файлов с простым 
построчно расположенным текстом. Все базы данных, используемые в Опіх 
для системного администрирования (пользователей и паролей, конфигура- 
ции сети и т.д.), организованы в виде файлов с простым текстом. (Ради оп- 
тимизации в некоторых системах поддерживается также бинарная форма 
определенных баз данных. При этом версия базы данных в простом тексте 
хранится для сопряжения с ее бинарной версией.) 


Если система выйдет из строя, для ее восстановления, возможно, придет- 
ся иметь дело с минимальной средой, не имея, например, доступа к графи- 
ческим драйверам. В подобных случаях можно по достоинству оценить не- 
сложность простого текста. 


Кроме того, простой текст проще для поиска. Так, если вы не помните, какой 
именно файл конфигурации управляет созданием резервных копий систе- 
мы, команда дхер -г БасКар /е&с поможет вам быстро найти его. 
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Упрощение тестирования 

Если вы пользуетесь простым текстом, чтобы сформировать синтетические 
данные для тестирования системы, в таком случае вам достаточно ввести, об- 
НОВИТЬ ИЛИ модифицировать тестовые данные, даже не создавая для этого спе- 
циальные инструментальные средства. Аналогично результаты регрессионного 
тестирования, выведенные простым текстом, совсем не трудно проанализиро- 
вать с помощью команд оболочки или простого сценария. 


НАИМЕНЬШИЙ ОБЩИЙ ЗНАМЕНАТЕЛЬ 


Вездесущие текстовые файлы понадобятся даже в будущих интеллектуаль- 
ных агентах на основе блокчейна, автономно перемещающихся в дикой и опас- 
ной среде Интернета, для согласования обмена данными. В действительности 
преимущества простого текста в гетерогенных средах перевешивают все их не- 
достатки. Нужно лишь обеспечить общение всех сторон по общему стандарту. 
И таким стандартом является простой текст. 


Другие разделы, связанные с данной темой 
• Тема 17. Игры в скорлупки. 


• Тема 21. Манипулирование текстом. 


® Тема 32. Конфигурирование, глава 5 “Гибкость или ломкость”. 


Задача 


• Спроектируйте на избранном вами языке небольшую базу данных для хра- 
нения адресной книги (Ф.И.О., номера телефонов и т.д.), используя про- 
стое бинарное представление. Сделайте это, прежде чем читать остальную 
часть этой задачи. 


- Преобразуйте данный формат в простой текст формата ХМІ или ЈЅОМ. 


— Добавьте для каждой версии новое поле переменной длины ді гесііопѕ, 
в котором можно было бы ввести направления к дому каждого лица, 
указанного в адресной книге. 


Какие вопросы, связанные с контролем версий и расширяемостью, у вас 
возникнут? Какую форму легче видоизменить? А как насчет преобразова- 
ния имеющихся данных? 


ТС АА ира р ре ое лета ки еле ау шедАНит РЕСТОРАНЕ И И о 
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Игры В СКОРЛУПКИ 


Каждому столяру требуется хороший, прочный и надежный верстак, где 
можно было бы закрепить заготовки на такой высоте, чтобы их было удобно об- 
рабатывать. Таким образом, верстак становится центром столярной мастерской, 
в которую мастер будет периодически возвращаться по мере того, как заготовка 
станет приобретать нужную форму. 

Для программиста, манипулирующего текстовыми файлами, таким верста- 
ком служит командный процессор, иначе называемый просто оболочкой. По 
приглашению из командной строки оболочки можно вызывать весь арсенал 
инструментальных средств, объединяя их с помощью конвейеров так, как это и 
не снилось их разработчикам. Из оболочки можно также запускать приложения, 
отладчики, браузеры, редакторы и утилиты, искать файлы, запрашивать состо- 
яние систем и фильтровать выводимые результаты. Программируя на уровне 
оболочки, можно строить сложные макрокоманды для автоматизации часто вы- 
полняемых действий. 

Для программистов, привыкших работать с использованием графических 
интерфейсов пользователя и интегрированных сред разработки, такой вариант 
может показаться крайним. Поэтому у них может возникнуть вполне резонный 
вопрос: нельзя ли одновременно пользоваться как оболочкой для ввода команд, 
так и графическим интерфейсом пользователя для манипулирования мышью? 

Самый простой ответ на этот вопрос отрицательный. СОТ, безусловно, при- 
мечательны тем, что позволяют быстрее и удобнее выполнять простые опера- 
ции. Перемещение файлов, чтение и запись сообщений электронной почты, 
построение и развертывание проекта — все эти операции обычно требуется 
выполнять в графической среде. Но если делать всю свою работу только в гра- 
фическом интерфейсе пользователя, то вряд ли удастся раскрыть полностью 
истинный потенциал своей рабочей среды и, в частности, автоматизировать ти- 
пичные задачи или использовать весь потенциал доступных инструментальных 
средств, а также объединять их, создавая специализированные макрокоманды. 
Главное преимущество графического интерфейса пользователя заключается в 
том, что он действует по принципу У/УЗГУУС (уһаї уои ѕее 15 уһаї уои реї — 
что видишь, то и получишь). Но главным его недостатком является принцип 
ҰҮГҮЅІАҮС (уһаќ уоц ѕее 15 2/1 уои реї — получишь лишь то, что видишь). 

Возможности графических сред, как правило, ограничиваются теми целями, 
которые преследовали их разработчики. Если же требуется выйти за переде- 
лы той модели поведения графической среды, которая была предусмотрена ее 
разработчиками (что требуется чаще, чем хотелось бы), то сделать это вряд ли 
удастся. Программисты-прагматики не просто специализируются на написании 
кода, разработке объектных моделей или составлении документа, а делают все 
это сами. Область действия любого инструмента обычно ограничивается теми 
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задачами, для выполнения которых он предназначен. Допустим, в интегриро- 
ванную среду разработки требуется встроить препроцессор кода, чтобы реали- 
зовать принципы проектирования по контракту или многопоточной обработки. 
Сделать это не удастся, если разработчик интегрированной среды разработки не 
предоставил явно соответствующие функциональные возможности. 


Используйте всю мощь командных оболочек 


Освойте оболочку как следует, и производительность вашего труда не за- 
медлит резко возрасти. Так, если требуется составить список всех однозначных 
имен пакетов, явно импортируемых в коде Јауа, его можно сохранить в файле 
11$ с помощью следующей команды, вызываемой из оболочки: 


зћҺ/раскадез . зһ 
агер '^1трогЕ ' *.јауа | 
зеа:=е' у трое ж/е вии" 1] 
ѕогі -и >]1ізѕі 
Такая команда может выглядеть пугающе, если вы не уделяли должного вре- 
мени изучению функциональных возможностей командных оболочек тех сис- 
тем, которыми пользуетесь. Все же немного потрудитесь, чтобы поближе озна- 
комиться с доступной вам командной оболочкой, и вскоре все станет на свои 
места. Поэкспериментировав с ней, вы с удивлением обнаружите, насколько 
возрастет производительность вашего труда. 


ВАША СОБСТВЕННАЯ ОБОЛОЧКА 


Подобно тому, как столяр упорядочивает свое рабочее место и подгоняет его 
под себя, разработчик должен специально настроить свою оболочку. Как прави- 
ло, это подразумевает также изменение конфигурации применяемой терминаль- 
ной программы. Ниже перечислены типичные изменения, которые требуется 
внести при этом. 


® Установка цветовых тем. Опробование каждой такой темы, доступной 
в оперативном режиме для конкретной оболочки, может отнять немало 
времени. 


® Настройка приглашения. Приглашение, которое сообщает о готовности 
оболочки к вводу команд, можно настроить на отображение лишь самой 
необходимой информации, поскольку остальная его часть вряд ли вообще 
понадобится. И здесь явно проявляются личные предпочтения. Нам, на- 
пример, больше нравятся простые приглашения, где в укороченной форме 
указано имя текущего каталога, текущая версия оболочки и время. 
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Псевдонимы и функции оболочки. Упростите свой рабочий процесс, пре- 
образовав в простые псевдонимы те команды, которыми вы часто пользу- 
етесь. Так, если вы регулярно обновляете свою платформу Ипих, но в то 
же время можете забыть, в какой именно последовательности следует это 
делать: обновлять и модернизировать или же модернизировать и обнов- 
лять, создайте для данной цели псевдоним, как показано ниже. 

а11аз ар*-ир='зиао арі-деі ирЧаее && зао арі-деі прагаае' 


Если вы случайно удалили файлы командой гт, отметив, что делаете это 
слишком часто, создайте на будущее следующий псевдоним, чтобы всегда 
ВЫВОДИТЬ соответствующее приглашение: 

а11аз км ='гм -1у' 

Автозавершение команд. В большинстве оболочек поддерживается авто- 
завершение команд и файлов: достаточно набрать несколько первых сим- 
волов, нажать клавишу табуляции, и оболочка постарается автоматичес- 
ки завершить ввод той команды, которую вы подразумеваете. Но можно 
пойти еще дальше, настроив оболочку таким образом, чтобы распознавать 
вводимые команды, предлагая контекстно-зависимые варианты их завер- 
шения, а иногда даже делая это в зависимости от текущего каталога. 


Вам придется немало времени работать в одной из таких оболочек". Будьте 
как рак-отшельник, сделав оболочку своим обиталищем. 


Другие разделы, связанные с данной темой 


Тема 13. Прототипы и памятные записки, глава 2 “Прагматичный подход". 
Тема 16. Сила простого текста. 
Тема 21. Манипулирование текстом. 


Тема 30. Преобразовательное программирование, глава 5 “Гибкость или 
ломкость’. 


Тема 51. Начальный набор инструментальных средств программиста-праг- 
матика, глава 9 “Прагматичные проекты”. 


Задачи 


Есть ли какие-нибудь операции, которые вы в настоящее время выполняе- 
те в СОТ: Даете ли вы своим коллегам какие-то инструкции, включающие 
в себя такие действия, как, например, “щелкни на этой кнопке” или “выбе- 
ри этот элемент”? Можно ли их как-то автоматизировать? 


® Всякий раз, когда вы переходите в новую среду, постарайтесь выяснить, 


какие в ней имеются командные оболочки и не удастся ли вам перенести 
свою текущую оболочку в новую среду. 


2 Игра слов: зВеЙ (англ.) — оболочка, ракушка. — Примеч.пер. 
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® Изучите альтернативы своей текущей оболочке. Если окажется, что ваша 
командная оболочка не справляется со своими обязанностями, выясните, 
сможет ли справиться с ними лучше альтернативная оболочка. 


О О И ОР О КА 


ЭФФЕКТИВНОЕ РЕДАКТИРОВАНИЕ 


Как упоминалось ранее, рабочие инструменты являются продолжением рук 
мастера. И это относится к текстовым редакторам даже в большей степени, чем 
к любым другим программным средствам. Ведь у вас должна быть возможность 
манипулировать текстом, прилагая как можно меньше усилий, поскольку текст 
служит сырьевым материалом для программирования. 

В первом издании этой книги мы настоятельно рекомендовали пользоваться 
одним и тем же редактором для выполнения самых разных операций: програм- 
мирования, документирования, памятных записок, системного администриро- 
вания и т.д. Но теперь мы немного смягчили свою позицию, рекомендуя исполь- 
зовать сколько угодно редакторов, поскольку сами стремимся умело работать с 
текстом в каждом из них. 


Стремитесь свободно владеть редактором 


Почему это так важно? Не хотим ли мы просто сказать о том, что это сэконо- 
мит нам массу времени? По сути, да: ведь за год вы сможете сэкономить целую 
неделю, повысив эффективность редактирования текста лишь на 4% (если, ко- 
нечно, вам приходится делать это по 20 часов в неделю). 

Но настоящая выгода состоит даже не в этом, а в том, чтобы, научившись 
свободно владеть редактором, вы больше не задумывались о самом механизме 
редактирования. Благодаря этому сокращается промежуток между осмыслением 
чего-нибудь и появлением результата в буфере редактора. От этого ваше програм- 
мирование только выигрывает, поскольку поток ваших мыслей не прерывается. 
(Если вам приходилось учить кого-нибудь вождению автомобиля, то вы хорошо 
знаете, насколько начинающий водитель, обдумывающий каждое свое действие, 
отличается от опытного водителя, интуитивно управляющего автомобилем.) 


Что ОЗНАЧАЕТ СВОБОДНОЕ ВЛАДЕНИЕ РЕДАКТОРОМ 


Ниже перечислены задачи редактирования текста, которые проясняют, что 
значит свободно владеть редактором. 


• Перемещение и выделение теста по отдельным символам, словам, строкам 
и абзацам. 
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® Перемещение различных синтаксических единиц (совпадающих ограничи- 
телей, функций, модулей и т.д.) 


® Повторное форматирование исходного кода с отступами после внесения 
изменений. 


• Комментирование и раскомментирование блоков кода одной командой. 
® Отмена и повтор изменений. 


® Разбиение окна редактора на несколько панелей и перемещение между 
НИМИ. 


• Перемещение на строку с конкретным номером. 
® Сортировка выбранных строк. 


ә Поиск как по символьным строкам, так и по регулярным выражениям и 
повторение предыдущего поиска. 


е Временное создание нескольких курсоров по выделенному тексту или 
совпадению с шаблоном и параллельное редактирование текста в позиции 
каждого курсора. 


• Отображение ошибок компиляции в текущем проекте. 


• Выполнение тестов в текущем проекте. 


Сможете ли вы сделать все это, не пользуясь мышью, сенсорной панелью или 
иным координатно-указательным устройством? Конечно, вы можете сказать, что 
текущий редактор не позволяет выполнить некоторые из перечисленных выше 
задач. В таком случае вам, может быть, стоит сменить редактор? 


СТРЕМЛЕНИЕ К СВОБОДНОМУ ВЛАДЕНИЮ РЕДАКТОРОМ 


Мы не сомневаемся, что найдется больше десятка людей, знающих все коман- 
ды в конкретном эффективном редакторе, но в то же время готовы предполо- 
жить, что вы к их числу не относитесь. Поэтому предлагаем более прагматичный 
подход: изучить те команды редактора, которые упрощают работу с текстом. 

Рецепт этого довольно прост. Сначала проанализируйте свои действия во 
время редактирования. Всякий раз, когда вы ловите себя на том, что делаете 
что-нибудь повторяющееся, выработайте в себе привычку обдумать и найти 
лучший способ сделать это. 

Как только вы обнаружите новое полезное средство, непременно освойте его 
вплоть до автоматизма, чтобы пользоваться им, не задумываясь. Этого можно 
добиться лишь многократным повторением. Сознательно ищите возможности 
применить свои вновь приобретенные сверхнавыки (в идеальном случае — мно- 
го раз в течение рабочего дня). И через неделю или около того вы сможете поль- 
зоваться ими, даже не задумываясь. 
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Расширение возможностей редактора 


Большинство эффективных редакторов исходного кода построены на ядре, 
наращиваемом посредством расширений. Некоторые расширения поставляются 
вместе с редактором, тогда как другие могут быть внедрены впоследствии. 

Если вы натолкнетесь на какое-то очевидное ограничение применяемого 
вами редактора, поищите его расширение, позволяющее преодолеть это огра- 
ничение. Вероятнее всего, такие функциональные возможности требуются не 
только вам, и вполне возможно, что кто-нибудь уже опубликовал свое решение 
данной задачи. 

Не останавливаясь на этом, можете даже освоить язык расширений своего 
редактора. Научитесь пользоваться им для автоматизации некоторых часто пов- 
торяемых вами операций. Зачастую для этого потребуется лишь одна или две 
строки кода. 

Иногда можно пойти еще дальше, самостоятельно написав полноценное рас- 
ширение. В таком случае опубликуйте его. Ведь если оно понадобилось вам, то, 
скорее всего, понадобится и другим. 


Другие разделы, связанные с данной темой 


• Тема 7. Общайтесь!, глава 1 “Философия прагматизма”. 


Задачи 


® Откажитесь от автоповторов. Все привыкли делать следующее: нажимать 
клавишу <ВасК5расе>, ожидая автоповтора, чтобы удалить последнее на- 
бранное слово. Можем побиться об заклад, что вы уже поднаторели делать 
это в уме настолько, что можете точно рассчитать, когда отпустить данную 
клавишу. Поэтому отключите режим автоповтора, а вместо него освойте 
комбинации клавиш для перемещения, выбора и удаления символов, слов, 
строк и блоков. 


е Этот способ дается нелегко. Отставьте мышь или иное координатно-ука- 
зательное устройство в сторону, чтобы целую неделю редактировать текст 
только с помощью клавиатуры. В итоге вы обнаружите, что немало опе- 
раций манипулирования текстом вы в состоянии выполнять, не наводя 
курсор и не щелкая кнопкой мыши. Но этому нужно учиться, поэтому за- 
писывайте комбинации клавиш, которые осваиваете, старым и надежным 
способом, используя карандаш и бумагу. 


• В первые дни это заметно скажется на производительности вашего тру- 
да. Но, учась манипулировать текстом так, чтобы не убирать свои руки 
из исходного положения на клавиатуре, вы постепенно обнаружите, что 
редактируете текст быстрее и свободнее, чем раньше. 
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• Ищите пути для интеграции. Когда Дэйв писал эту главу, его посетила 
мысль: а нельзя ли предварительно просмотреть окончательную ее компо- 
новку (файл формата РОЕ) в буфере редактора. И как только он нашел и 
загрузил подходящее расширение, предварительно просматриваемый вид 
окончательной компоновки тотчас расположился рядом с текстом рукопи- 
си в том же самом текстовом редакторе. Итак, составьте список функцио- 
нальных возможностей, которыми вы хотели бы расширить свой редактор, 
а затем поищите их. 


® Если вам не удастся найти подходящее расширение или подключаемый 
модуль, напишите его, хотя это более честолюбивая задача. Энди нравит- 
ся создавать специальные, локальные файловые модули, подключаемые к 
его излюбленным редакторам для составления вики-страниц. Если вам не 
удастся найти такой подключаемый модуль, создайте его сами! 
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Контроль ВЕРСИЙ 


“Прогресс не проявляется лишь в изменениях и зависит 
от памятливости. Те, кто не учится на своих ошибках, 
обречены повторять их”. 


Джордж Сантаяна,? Жизнь разума (1 оў Веа5оп) 


К числу самых востребованных элементов пользовательского интерфейса от- 
носится кнопка отмены — как единственная возможность исправления ошиб- 
ки. Еще лучше, если в рабочей среде поддерживается несколько уровней отмены 
и повтора, чтобы можно было вернуться к тому, что было сделано пару минут 
назад. 

Но что, если ошибка была совершена на прошлой неделе, и с тех пор компью- 
тер неоднократно включался и выключался? Именно в таких случаях и прояв- 
ляется одно из многих преимуществ системы контроля версий как гигантской 
кнопки отмены, которая, словно машина времени, позволяет вернуться к той 
благополучно завершенной на прошлой неделе стадии проекта, когда исходный 
код компилировался и выполнялся. 

Многие разработчики ограничиваются именной этой возможностью, поль- 
зуясь системой контроля версий. Они упускают из виду всю намного более об- 
ширную область — сотрудничества, конвейерного развертывания, отслеживания 
ошибок и общего взаимодействия членов команды. Поэтому рассмотрим систе- 
му контроля версий сначала как хранилище изменений, а затем как центральное 
место встреч, где члены команды встречаются со своим исходным кодом. 


7 Сеогре Зат{ауапа — американский философ и писатель ХХ века испанского происхож- 
дения. — Примеч. пер. 
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_ СОВМЕСТНО ИСПОЛЬЗУЕМЫЕ КАТАЛОГИ — ЭТО НЕ СИСТЕМА КОНТРОЛЯ ВЕРСИЙ 


Нам до сих пор встречаются иногда такие команды, которые обмениваются 
исходными файлами своих проектов по сети: как внутренним образом, так и 
с помощью определенного рода облачного хранилища. Но это непрактично. 


Команды, поступающие подобным образом, приводят работу друг друга 
в полный беспорядок, теряют изменения и нарушают сборки, словно идя 
стенка на стенку за место на парковке автомобилей. Это можно сравнить 
с написанием параллельного кода с совместно используемыми данными и 
без механизма синхронизации. Вместо этого лучше пользоваться системой 
контроля версий. 


Более того, некоторые разработчики пользуются системой контроля вер- 
сий, организуя ее основной репозиторий в сети или в облачном хранилище. 
Они считают такое решение обоюдовыгодным, поскольку их файлы доступ- 
ны отовсюду и резервируются в удаленном месте (если речь идет об облач- 
ном хранилище). 


На самом же деле это еще хуже, поскольку есть риск потерять все. В систе- 
ме контроля версий применяется ряд взаимодействующих файлов и катало- 
гов, и если изменения вносятся одновременно в два экземпляра, то общее 
их состояние может быть нарушено, а о степени нанесенного ущерба ниче- 
го не сообщается. Вряд ли кому-нибудь будет приятно видеть, как разработ- 
чики воют от отчаяния. 


ВСЕ НАЧИНАЕТСЯ С ИСХОДНОГО КОДА 


Системы контроля версий следят за каждым изменением, вносимым в исход- 
ный код и документацию. Настроив такую систему надлежащим образом, мож- 
но всегда вернуться к предыдущей версии своего программного обеспечения. 

Но возможности системы контроля версий далеко не ограничиваются отме- 
ной ошибок. Хорошая система контроля версий позволяет отслеживать вноси- 
мые изменения, отвечая на такие вопросы, как, например, следующие: кто внес 
изменения в конкретной строке кода, чем текущая версия отличается от той, 
что была на прошлой неделе, какие файлы изменяются чаще всего? Такого рода 
сведения бесценны для целей отслеживания программных ошибок, ревизии, по- 
вышения производительности и качества. 

Кроме того, система контроля версий позволяет идентифицировать выпуски 
программного обеспечения. Указав конкретную выпускаемую версию, можно 
всегда вернуться и сформировать ее снова, сделав это независимо от внесен- 
ных впоследствии изменений. Системы контроля версий позволяют отслежи- 
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вать файлы, хранящиеся в центральном репозитории, вполне подходящем для 
архивирования. 

Наконец, системы контроля версий дают двум или большему количеству 
пользователей возможность работать параллельно над одним и тем же рядом 
файлов и даже вносить одновременные изменения в один и тот же файл. Систе- 
ма контроля версий сама объединит эти изменения, когда файлы будут отправ- 
лены обратно на хранение в репозиторий. Несмотря на кажущийся риск, такие 
системы вполне пригодны для практического применения в проектах любых 
масштабов. 


Всегда пользуйтесь системой контроля версий 


Делайте это всегда, даже если работаете над индивидуальным или краткос- 
рочным проектом, “одноразовым” прототипом или иным материалом, не явля- 
ющимся исходным кодом. При этом все версии должны быть под полным кон- 
тролем, будь то документация, списки номеров телефонов, памятные записки 
для поставщиков, сборочные файлы, процедуры сборки и выпуска, небольшой 
сценарий оболочки, упорядочивающий журнальные файлы, словом — все. Мы 
регулярно пользуемся контролем версий практически для всего, что набираем 
сами, включая текст этой книги. И даже если мы не работаем над конкретным 
проектом, то все равно сохраняем для надежности свою повседневную работу 
в репозитории. 


ВЕТВЛЕНИЕ 


В системах контроля версий не только отслеживается предыстория конкрет- 
ного проекта. К числу самых эффективных и полезных свойств таких систем 
относится возможность выделять отдельные участки разработки в так назы- 
ваемые ветви. Создать ветвь можно в любой момент предыстории проекта, и 
тогда любая работа, выполняемая в данной ветви, будет обособлена от всех ос- 
тальных ветвей. А в какой-то последующий далее момент свою рабочую ветвь 
можно объединить обратно с другой ветвью, чтобы целевая ветвь содержала в 
итоге изменения, внесенные в рабочей ветви. Более того, в одной ветви могут 
работать несколько человек, и такие ветви становятся похожими в какой-то сте- 
пени на небольшие клонируемые проекты. 

Ветви выгодно отличаются, во-первых, тем, что позволяют работать обособ- 
ленно. Так, если вы разрабатываете функциональное средство А в одной ветви, 
а ваш коллега — функциональное средство В в другой ветви, вы не мешаете 
друг другу. И во-вторых, ветви, как ни странно, нередко оказываются в центре 
процесса работы команды над проектом. 
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Именно здесь и возникает небольшая путаница. У ветвей контроля версий 
и организации тестов есть нечто общее: и в тех и в других участвуют тысячи 
людей, подсказывающих, как нужно делать. Но такие советы по большей части 
лишены смысла, поскольку они, по существу, означают прием, который оказался 
пригодным для советчика в конкретной ситуации. 

Итак, пользуйтесь контролем версий в своем проекте, и если в процессе ра- 
боты над ним у вас возникнут какие-нибудь затруднения, то поищите возмож- 
ные пути их разрешения. И не забывайте просматривать и корректировать все, 
что вы делаете, постепенно набираясь необходимого опыта. 


Мысленный ЭКСПЕРИМЕНТ 


Вылейте чашку вашего любимого чая на клавиатуру своего компьютера. От- 
несите его в мастерскую по ремонту вычислительной техники, задав им ра- 
боту. Если они не сумеют починить ваш компьютер, приобретите новый. 


Сколько времени потребуется, чтобы вернуть компьютер в прежнее состо- 
яние, включая установку и настройку операционной системы, сетевого про- 
токола, текстового редактора, приложений и т.д., когда вы только подняли 
злосчастную чашку чая? Подобный вопрос пришлось недавно решать одно- 
му из авторов этой книги. 


Практически все, что определяло конфигурацию и применение первона- 
чального компьютера, хранилось в системе контроля версий, в том числе 
следующее: 


® Все пользовательские настройки и файлы конфигурации. 
® Параметры настройки текстового редактора. 


® Список программного обеспечения, установленного с помощью утилиты 
командной строки типа Нотебгему. 


® Сценарий АпѕіЫіе для конфигурирования приложений. 
® Все текущие проекты. 


К вечеру компьютер был восставлен в прежнее рабочее состояние. 


КонтрОЛЬ ВЕРСИЙ КАК ЦЕНТРАЛЬНЫЙ УЗЕЛ ПРОЕКТА 


Несмотря на то что контроль версий невероятно удобен для работы над ин- 
дивидуальными проектами, истинный его потенциал проявляется в коллектив- 
ной работе. И наибольшая его ценность заключается в том, как организовано 
размещение репозитория. 


Тема 19 + Контроль версий 123 


Многим современным системам контроля версий вообще не требуется ни- 
какого размещения. Они полностью децентрализованы, и поэтому все разра- 
ботчики могут на равных работать над совместным проектом. Но даже в таких 
системах стоит все же организовать центральный репозиторий. Ведь в этом 
случае можно многократно выполнять интеграцию, упрощая ход работы над 
проектом. 

Многие репозиторные системы доступны в виде открытого исходного кода, 
что дает возможность установить их и работать с ними в своей организации. Но 
для программистов-прагматиков мы все же рекомендуем размещать репозито- 
рий системы контроля версий на третьей стороне, где следует искать перечис- 
ленные ниже возможности. 


® Хорошая защита и управление доступом. 
• Интуитивный пользовательский интерфейс. 


• Возможность выполнять все операции из командной строки на тот случай, 
если потребуется автоматизировать их. 


» Автоматическое построение и тестирование. 


• Хорошая поддержка объединения ветвей, иногда еще называемого запро- 
сами на включение изменений. 


® Разрешение затруднений (в идеальном случае интегрировано в операции 
фиксации изменений и объединения ветвей для сохранения количествен- 
ных показателей). 


® Хорошая отчетность (может оказаться удобным отображение неразрешен- 
ных вопросов и задач). 


• Удобное общение в команде: уведомления об изменениях по электронной 
почте или иными способами, вики-страницы и пр. 


Многие команды настраивают свои системы контроля версий таким обра- 
зом, чтобы отправка изменений в конкретную ветвь автоматически приводила 
к построению системы, выполнению тестов, а после успешного завершения — к 
развертыванию нового кода в условиях эксплуатации. На первый взгляд такая 
автоматизация операций вызывает опасение, но в ней нет ничего опасного, если 
ясно осознавать сущность контроля версий: любые изменения можно всегда от- 
катить назад. 


Другие разделы, связанные с данной темой 
® Тема 11. Обратимость, глава 2 “Прагматичный подход”. 


• Тема 49. Прагматичные команды, глава 9 “Прагматичные проекты". 


ө Тема 51. Начальный набор инструментальных средств программиста-праг- 
матика, глава 9 “Прагматичные проекты”. 
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Задачи 


® Одно дело — знать, как произвести откат в предыдущее состояние, ис- 
пользуя систему контроля версий, а другое — уметь это делать. Можете ли 
вы произвести такую операцию и знаете ли подходящие для этой цели ко- 
манды? Овладейте ими сейчас, а не тогда, когда нагрянет беда и придется 
принимать срочные меры. 


• Обдумайте, как вы будете восстанавливать рабочую среду на переносном 
компьютере после аварийной ситуации. Что именно вам придется восста- 
навливать? Иногда требуется восстановить лишь текстовые файлы. Если 
они не находятся в системе контроля версий, размещаемой в удаленном 
месте, найдите способ ввести их в эту систему. Затем подумайте о другом 
материале: установленных приложениях, конфигурации системы и т.д. Как 
выразить весь этот материал в текстовых файлах, чтобы сохранить и его: 
Добившись некоторого прогресса, попробуйте в качестве любопытного 
эксперимента отыскать старый компьютер, которым вы больше не поль- 
зуетесь, и выяснить, можно ли настроить его, используя новую систему 
контроля версий. 


® Сознательно подойдите к исследованию тех различных возможностей ва- 
шей системы контроля версий и хостинга, которыми вы в настоящее вре- 
мя не пользуетесь. Так, если в вашей команде не применяются функцио- 
нальные ветви, поэкспериментируйте с их внедрением. Это же относится 
к запросам на извлечение или включение изменений, непрерывной интег- 
рации, сборочным конвейерам и даже к непрерывному развертыванию. 
Поищите средства, подходящие для общения в команде, в том числе вики- 
страницы, доски по методу канбан и пр. Пользоваться всем этим совсем 
не обязательно, но все же нужно знать, чем они могут помочь в принятии 
решений. 


е Пользуйтесь контролем версий и для работы с другим материалом вне 
своего проекта. 


Е КР И И О ПИ И НИ И 


ОтлАДКА 


<< 
Как больно глядеть на свои страданья и знать, что 
причинил их ты сам, и никто другой”. 


Софокл, Аякс 


Слово рис (жучок) служит в английском языке для описания “ужасного объ- 
екта” еще с ХІУ века. Контр-адмирал д-р Грэйс Хоппер, создатель языка СОВОГ, 
была первым наблюдателем компьютерного “жучка”, а по существу, моли, попав- 
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шей в одно из реле, на которых были построены первые ЭВМ. Когда техника из 
обслуживающего персонала попросили объяснить, почему машина ведет себя 
не так, как следует, он ответил, что обнаружен “жучок в системе’, и с сознанием 
выполненного долга приклеил насекомое (вместе с крылышками и всем осталь- 
ным) клейкой лентой к странице регистрационного журнала. 

К сожалению, “жучки” до сих пор попадают в вычислительные системы, хотя 
они и не летают. Впрочем, их лучше было бы назвать бытующим с ХІУ века сло- 
вом рореутап и означающим “призрак”, поскольку теперь оно уместно в гораздо 
большей степени, чем на заре вычислительной техники. Изъяны проявляются в 
программном обеспечении по-разному: от превратно понятых требований до 
ошибок программирования. И, к сожалению, современные вычислительные сис- 
темы способны делать лишь то, что мы им прикажем, но совсем не обязательно 
то, что нам хотелось бы, чтобы они делали. 

Никому не удается писать идеальные программы, а следовательно, их отладка 
занимает львиную долю рабочего времени программиста. Рассмотрим некото- 
рые вопросы, касающиеся отладки, а также ряд общих стратегий обнаружения 
едва уловимых программных ошибок. 


Психология отлАДКИ ПРОГРАММ 


Для многих разработчиков отладка является довольно щепетильной, чувс- 
твительной темой. Вместо желания приступить к ней как к требующей разгад- 
ки головоломке, можно встретить отказ, взаимные упреки, слабые отговорки 
и просто безразличие. Следует, однако, иметь в виду, что отладка — это всего 
лишь средство для разрешения затруднений и их устранения. 

Обнаружив чью-нибудь программную ошибку, можно затратить немало вре- 
мени и труда, возлагая всю вину на того нечестивца, который ее совершил. В не- 
которых ситуациях и коллективах это оказывается (очистительной) частью об- 
щей культуры. Но в области техники требуется сосредоточиться на устранении 
самого затруднения, а не винить других в его возникновении. 


Устраните затруднение, а не вините в нем других 
И совсем не важно, является ли программная ошибка вашей или чужой оп- 
лошностью. Она все равно остается вашей проблемой. 


Мысленнлщя УСТАНОВКА НА ОТЛАДКУ 


“Обманывать легче всего самого себя”. 
Эдвард Булвер-Литтон*, Отвергнутый (Тһе Ріѕомпей) 


* Едуагі Вшмег-Іуйоп — английский писатель ХІХ века. — Примеч. пер. 
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Прежде чем приступить к отладке, очень важно принять соответствующий 
образ мыслей. Для этого необходимо устранить многие преграды, защищающие 
ваше самолюбие, избавиться от любого возможного нажима со стороны проек- 
та и почувствовать себя в уютной обстановке. А самое главное — не забывать 
первое правило отладки, которое гласит: 


Не паникуй! 


Впасть в панику очень легко, особенно если поджимают сроки или нервни- 
чающий начальник либо клиент дышит вам в затылок в то время, как вы пыта- 
етесь найти причину программной ошибки. И здесь очень важно отступить на 
шаг и тщательно обдумать возможную причину тех симптомов, которые, на ваш 
взгляд, указывают на программную ошибку. 

Если вашей первой реакцией на свидетельство или сообщение о програм- 
мной ошибке станет фраза “это невозможно”, значит, вы совершенно не правы. 
Не тратьте ни одного нейрона на ход рассуждений, начинающийся с того, что 
этого просто не может быть. Ведь совершенно очевидно, что это может быть, 
и так оно и есть. 

Стерегитесь близорукости во время отладки. Противьтесь сильному желанию 
устранить лишь видимые симптомы, ведь фактическая неисправность может от- 
стоять на несколько шагов от того, что вы наблюдаете, и быть связанной с це- 
лым рядом других неполадок. Старайтесь всегда обнаружить корневую причину 
возникшего затруднения, а не только его конкретное внешнее проявление. 


С ЧЕГО НАЧИНАТЬ ОТЛАДКУ 


Прежде чем приступить к анализу программной ошибки, убедитесь, что ра- 
ботаете над кодом, при построении которого не было никаких предупреждений 
компилятора. Нет никакого смысла тратить время, пытаясь выявить неполадку, 
которую компьютер может обнаружить автоматически! Вам нужно сосредото- 
читься на решении более трудных насущных задач. 

Пытаясь разрешить любое затруднение, необходимо собрать все уместные 
данные. К сожалению, сообщения о программных ошибках для этого не совсем 
годятся из-за своей неточности. Ведь совпадения могут очень легко ввести в 
заблуждение, а тратить время на отладку совпадений непозволительно. Прежде 
всего необходимо быть точным в своих наблюдениях. 

Точность сообщений о программных ошибках снижается еще больше, когда 
они проходят через стороннее программное обеспечение. Чтобы добиться до- 
статочного уровня детализации, возможно, придется понаблюдать за действия- 
ми пользователя, сообщившего о программной ошибке. 
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Однажды Энди работал над крупным графическим приложением. Ближе 
к выпуску этого приложения тестировщики сообщили, что оно завершалось 
аварийно всякий раз, когда они наносили мазок конкретной кистью. Програм- 
мист, отвечавший за эту часть приложения, возразил, что в таком поведении 
нет ничего неверного. Он попробовал раскрасить участок изображения данной 
кистью, и она действовала как следует. Эта полемика продолжалась в течение 
нескольких дней, и всякий раз на быстро повышавшихся тонах. 

Наконец, мы собрались вместе в одном помещении. Тестировщик выбрал 
инструмент кисти и нанес мазок от правого верхнего до нижнего левого угла 
экрана, в результате чего приложение перестало работать. Программист удив- 
ленно воскликнул сдавленным голосом и смущенно признался, что наносил 
пробные мазки кистью только от нижнего левого до правого верхнего угла эк- 
рана, что не приводило к появлению ошибки. 

Из этой истории можно сделать следующие выводы. 


® С пользователем, сообщившим о программной ошибке, возможно, придет- 
ся побеседовать, чтобы получить больше сведений, чем удалось собрать 
первоначально. 


® Искусственных тестов вроде единственного мазка, проведенного кистью 
снизу вверх, недостаточно для проверки приложения. Необходимо подвер- 
гнуть безжалостному тестированию как граничные условия, так и реалис- 
тичные образцы его употребления конечным пользователем. И делать это 
следует систематически (см. раздел “Строгое и непрерывное тестирование” 
главы 9 “Прагматичные проекты”). 


СТРАТЕГИИ ОТЛАДКИ 


Как только вы определите, что, собственно, происходит, выясните, как это 
представляется в самой программе. 


Воспроизведение ошибок 


Нет, наши ошибки в действительности не размножаются (хотя некоторые из 
них, вероятно, достаточно стары, чтобы это было законным). Речь здесь идет о 
другом способе размножения. 

Чтобы приступить к устранению программной ошибки, ее нужно сделать 
воспроизводимой. Ведь если воспроизвести ошибку нельзя, то как выяснить, 
была ли она вообще устранена? 

Но ведь нам требуется выяснить нечто большее, чем программная ошибка, 
которая может быть воспроизведена путем выполнения некоторой длинной пос- 
ледовательности шагов. Мы хотим, чтобы можно было воспроизвести програм- 
мную ошибку с помощью единственной команды. Ведь устранить программную 
ошибку намного сложнее, если, чтобы дойти до того места, где она проявляется, 
придется выполнить 15 шагов. Поэтому самое важное правило отладки гласит: 
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Вылавливающий ошибку тест должен предшествовать 
ее исправлению 


Иногда, пытаясь выделить обстоятельства, при которых проявляется ошиб- 
ка, можно Даже получить ясное представление, как ее устранить. Сам процесс 
написания теста подсказывает нужное решение. 


ПРОГРАММИСТ В ЧУЖОЙ СТРАНЕ 


Все сказанное выше о локализации программной ошибки, конечно, замеча- 
тельно. Но что делать бедному программисту, если требуется отладить 50 тысяч 
строк кода, когда времени явно не хватает? 

Прежде всего рассмотрите проблему. Идет ли речь об аварийном завершении 
приложения? Когда мы преподаем на курсах, включающих программирование, 
нас всегда удивляет, как много разработчиков, увидев появление исключения в 
красном поле результатов тестирования, сразу же переходят к исходному коду. 


Внимательно читайте сообщение об ошибке, 
каким бы отвратительным оно ни было 


К этому добавить нечего. 


Плохие результаты 


А что, если это не аварийное завершение, а всего лишь плохой результат? 
В таком случае перейдите в отладчике к месту его формирования и выполните 
тест, чтобы выявить ошибку. 

Прежде чем делать что-нибудь другое, непременно выявите неверное зна- 
чение в отладчике. Мы оба часами пытались отследить программную ошибку 
лишь затем, чтобы обнаружить, что данное конкретное выполнение кода завер- 
шилось удачно. 

Иногда ошибка вполне очевидна. Например, значение переменной 1п%егезе _ 
кафе равно 4.5, а должно быть равно 0.045. Но чаще всего ошибку приходит- 
ся искать глубже, чтобы выяснить, прежде всего, причину, по которой значение 
оказалось неверным. Поэтому убедитесь сначала, что знаете, как перемещаться 
вверх и вниз по стеку вызовов, а затем проанализируйте окружение стека. 

Нередко полезно держать под другой лист бумаги и ручку, чтобы делать за- 
метки. В частности, мы часто находим ключ к разгадке и, идя по следу, не дости- 
гаем в конечном итоге успеха. И если не записать место, с которого мы начали 
свой поиск, то можно потерять много времени, возвращаясь назад. 

Иногда приходится анализировать результаты трассировки стека, прокрутка 
которых кажется бесконечной. В таком случае бинарный поиск нередко оказы- 
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вается более быстрым способом выявить неполадку, чем анализ всех фреймов 
стека подряд. Но, прежде чем обсуждать этот способ, рассмотрим две другие 
общие ситуации возникновения программных ошибок. 


Чувствительность ко входным данным 


Эта ситуация должна быть хорошо вам знакома. Сначала ваша программа 
нормально работает со всеми тестовыми данными и с честью переживает пер- 
вую неделю своей эксплуатации, а затем неожиданно терпит крах, когда в нее 
вводится некоторый конкретный массив данных. 

Вы можете попытаться проанализировать свою программу в месте ее ава- 
рийного завершения и продвигаться далее в обратном направлении. Сделайте 
копию массива данных и введите его в локальную копию своей программы, убе- 
дившись, что она по-прежнему терпит крах. Затем выполняйте бинарный поиск 
до тех пор, пока не дойдете до конкретного места, где вводимые значения при- 
водят к аварийному завершению. 


Регрессии по выпускам 


Представьте, что вы работаете в хорошей команде, выпускающей програм- 
мное обеспечение в эксплуатацию. В какой-то момент в исходном коде, который 
нормально работал еще неделю назад, обнаруживается программная ошибка. 
Не стоит ли в таком случае выявить конкретное изменение, внедрившее данную 
ошибку? И, как вы, вероятно, уже догадались, что самое время для бинарного 
поиска, о котором речь пойдет далее. 


БинАРНЫЙ ПОИСК 


Всякому студенту, изучавшему вычислительную технику, приходилось про- 
граммировать бинарный поиск, иначе называемый делением пополам. В его осно- 
ву положена довольно простая идея: найти конкретное значение в отсортирован- 
ном массиве. Для этого можно было бы, конечно, проанализировать поочередно 
каждое значение, но тогда пришлось бы перебрать в среднем около половины 
элементов массива до тех пор, пока не будет найдено требуемое или большее 
значение. Последнее означает, что искомое значение отсутствует в массиве. 

Но найти нужное значение можно намного быстрее, воспользовавшись мето- 
дом “разделяй и властвуй”. С этой целью выбирается значение посредине масси- 
ва. Если это искомое значение, то поиск прекращается, а иначе массив делится 
надвое. Если найденное значение больше искомого, то становится ясно, что оно 
должно быть в первой половине массива, а иначе — во второй. Данная про- 
цедура повторяется в соответствующем подмассиве, и очень скоро достигается 
искомый результат. (Как поясняется в разделе “Асимптотическое обозначение” 
главы 7 “По ходу кодирования’, линейный поиск имеет сложность О(и), а би- 
нарный — О(Іори)). 
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Таким образом, бинарный поиск позволяет намного быстрее решить любую за- 
дачу приличных масштабов. А теперь посмотрим, как применить его к отладке. 

Когда вы анализируете результаты массивной трассировки стека, пытаясь 
выяснить, какая именно функция ошибочно исказила значение, то выполняе- 
те бинарный поиск, выбрав кадр где-то посредине стека, чтобы посмотреть, не 
проявилась ли ошибка до этого места. Если она проявилась, то становится ясно, 
что основное внимание следует сосредоточить на предыдущих фреймах; в про- 
тивном случае следует искать неполадку в последующих фреймах стека. Затем 
бинарный поиск повторяется, и даже если в результатах трассировки стека при- 
сутствуют 64 кадра, подобным методом можно найти причину ошибки, сделав 
не более шести попыток. 

Если вы ищете программные ошибки, проявляющиеся в определенных мас- 
сивах данных, то можете поступить таким же образом, как описано выше. В час- 
тности, разделите массив данных надвое и выясните, проявится ли ошибка, если 
ввести одну или другую его половину в отлаживаемое приложение. Продолжай- 
те далее разделять массив данных до тех пор, пока не получите минимальный 
массив значений, в котором проявляется искомая ошибка. 

Если ваша команда внесла программную ошибку давно, и с тех пор прошло 
уже несколько выпусков, то и в этом случае можно воспользоваться тем же са- 
мым методом. С этой целью создайте тест, который не проходит в текущем вы- 
пуске, а затем выберите промежуточный вариант между текущей и последней 
версией, о которой заведомо известно, что она рабочая. Выполните тест снова, 
чтобы решить, каким образом следует сузить поиск. Возможность такого реше- 
ния — одно из многих преимуществ, которые дает наличие качественного кон- 
троля версий в ваших проектах. Безусловно, многие системы контроля версий 
позволяют пойти еще дальше и автоматизировать данный процесс, самостоя- 
тельно выбирая выпуски по результатам тестирования. 


Протоколирование и/или трассировка 


Как правило, отладчики сосредоточиваются на текущем состоянии програм- 
мы. Но иногда требуется нечто большее: наблюдать состояние программы или 
структуры данных во времени. Просмотр результатов трассировки стека поз- 
воляет лишь выяснить, как непосредственно дойти до текущего состояния. Он, 
как правило, не позволяет выяснить, что именно было сделано до данной цепоч- 
ки вызовов, особенно в событийно-управляемых системах”. 

Операторы трассировки являются небольшими диагностическими сообще- 
ниями, выводимыми на экран или в файл и уведомляющими, например, о том, 
что выполнение программы дошло до конкретного места или значение перемен- 
ной х стало равным 2. И хотя это довольно примитивный метод по сравнению 


с возможностями отладчиков в интегрированных средах разработки, он все же 


5 Хотя в языке Ет имеется отладчик, допускающий перемещение во времени. 
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особенно эффективен для диагностики нескольких классов ошибок, выявить 
которые отладчики неспособны. Трассировка неоценима в любой системе, где 
важным фактором в одновременно выполняющихся процессах, системах реаль- 
ного времени и событийно-управляемых приложениях является само время. Ис- 
пользуя операторы трассировки, можно подробно анализировать исходный код 
вглубь, т.е. вводить их, продвигаясь вниз по дереву вызовов. 

Сообщения трассировки должны быть представлены в обычном согласован- 
ном формате, чтобы их можно было анализировать автоматически. Так, если 
требуется проследить утечку ресурсов (например, неравномерность открытий и 
закрытий файлов), с этой целью можно протрассировать каждый оператор ореп 
и с1о5е в журнальном файле. Обрабатывая журнальный файл инструменталь- 
ными средствами для обработки текста или по командам оболочки, можно лег- 
ко определить место, где появился оператор ореп, нарушивший равномерность 
открытий и закрытий файлов. 


МЕТОД РЕЗИНОВОГО УТЕНКА 


Самый простой, но особенно полезный способ найти причину неполадки — 
просто объяснить ее кому-то другому. Он должен глядеть на экран через ваше 
плечо, постоянно кивая головой, как резиновый утенок, ныряющий и всплы- 
вающий в ванной. Не говоря ни слова, а просто показывая шаг за шагом, что 
именно должен делать код, нередко можно дойти до того, что неполадка выныр- 
нет на экран и проявится сама. 

Казалось бы, все просто, но, объясняя возникшее затруднение другому чело- 
веку, вам приходится растолковывать ему то, что может быть само собой разуме- 
ющимся для вас, когда вы просматриваете исходный код сами. Выражая слова- 
ми свои предположения, вы можете неожиданно получить новое представление 
о возникшем затруднении. А если вам некому объяснить свое затруднение, то 
вполне подойдет и резиновый утенок, плюшевый медвежонок или растение в 
горшке. 


Процесс исключения 


В большинстве проектов отлаживаемый прикладной код может состоять из 
фрагментов, написанных вами и другими членами команды, работающей над 
проектом, сторонних программных продуктов (базы данных, средств подклю- 
чения к сети, каркаса веб-приложений, специальных протоколов связи или ал- 


У Почему данный метод носит название “резинового утенка”? Когда Дэйв учился в Им- 
перском колледже Лондона, он много работал с младшим научным сотрудником Грегом 
Пафом (Стер Рирћ), одним из самых лучших из всех известных ему разработчиков. Грег 
целыми месяцами носил с собой небольшого желтого резинового утенка и ставил его на 
свой терминал, когда программировал. И лишь некоторое время спустя Дэйв отважился 
спросить, зачем Грег это делает... 
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горитмов и т.д.), а также платформенного окружения (операционной системы, 
системных библиотек и компиляторов). 

Вполне возможно, что программная ошибка присутствует в операционной 
системе, компиляторе или стороннем программном продукте, хотя это и не долж- 
но быть вашей первой мыслью. Ведь намного более вероятно, что программная 
ошибка присутствует в разрабатываемом прикладном коде. Как правило, предпо- 
ложить, что в прикладном коде неверно вызывается библиотека, целесообразнее, 
чем допустить, что нарушена сама библиотека. И даже если неполадка кроется 
в стороннем программном продукте, то нужно все равно устранить неполадки в 
своем коде, прежде чем предоставить отчет о программных ошибках. 

Нам как-то пришлось работать над проектом, где старший инженер был 
убежден, что системный вызов ѕе1есі нарушался в самой операционной систе- 
ме Опіх. И никакие убедительные доводы или логические обоснования не могли 
изменить его мнение, а тот факт, что все остальные сетевые приложения работа- 
ли на данной платформе нормально, не принимался во внимание. Он потратил 
не одну неделю, изобретая обходные пути, которые по какой-то странной при- 
чине все же не устраняли неполадку. И когда ему пришлось в конечном счете 
сесть и прочитать документацию на системный вызов ѕе1есё, он обнаружил и 
устранил неполадку в считанные минуты. С тех пор мы пользуемся выражением 
“системный вызов ѕе1есі нарушен” в качестве осторожного напоминания, как 
только один из нас начинает винить в сбое, который, вероятнее всего, происхо- 
дит по его вине, саму систему. 


Системный вызов зе1ес® работает нормально 


Увидев следы копыт, не забывайте подумать прежде всего о конях, а не зеб- 
рах. Операционная система скорее всего работает нормально, и системный вы- 
зов зе1ес® действует как следует. 

Если вы внесли изменение лишь в какой-то один компонент и система пере- 
стала работать, то, вероятнее всего, именно этот компонент, прямо или косвен- 
но, служит тому причиной, какой бы неправдоподобной она ни казалась. Иногда 
измененный компонент оказывается вне вашего поля зрения. Это может быть, 
например, новая версия операционной системы, компилятор или другое сторон- 
нее программное обеспечение, способное повредить код, который раньше рабо- 
тал нормально. Могут проявиться новые программные ошибки, нарушающие 
обходные пути, устраняющие обнаруженные ранее ошибки. Изменяются также 
АРІ, функциональные возможности. Короче говоря, возникает совсем новая 
ситуация, вынуждающая снова проверять всю систему в этих новых условиях. 
Поэтому внимательно следите за графиком выполнения работ, если планируете 
модернизацию, которую, возможно, придется отложить до момента после сле- 


дующего выпуска. 
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ЭЛЕМЕНТ УДИВЛЕНИЯ 


Если программная ошибка приведет вас в недоумение, а возможно, даже и к 
бормотанию шепотом “этого просто не может быть” так, чтобы никто не услы- 
шал, — в таком случае вам придется переоценить те истины, которыми вы так 
дорожите. Выполняя этот алгоритм учета поправки на преувеличение того, что 
казалось вам вполне надежным и не могло вызвать эту программную ошибку, 
спросите себя: проверили ли вы все граничные условия? И не кроется ли до сих 
пор программная ошибка в том фрагменте кода, которым вы пользуетесь года- 
ми? Возможно ли такое вообще? 

Конечно, возможно. Степень удивления, которое вы испытываете, когда что- 
нибудь не ладится, пропорциональна степени доверия и веры в непогрешимость 
выполняемого кода. Именно поэтому, сталкиваясь с “удивительным” сбоем, вы 
должны признать, что одно или несколько ваших предположений неверны. Не 
обходите стороной подпрограмму или фрагмент кода, связанный с ошибкой, 
лишь потому, что твердо уверены в его работоспособности. Убедитесь в том, 
что в таком контексте, с такими данными и при таких граничных условиях 
проверяемый код действительно работает. 


Не предполагайте, а доказывайте 


Обнаружив удивительную программную ошибку, необходимо не только ус- 
транить ее, но и установить причину, по которой ее не удалось перехватить. 
Выясните, следует ли исправить модульные или другие тесты, чтобы они могли 
выявлять данную ошибку. 

А если программная ошибка возникает в результате распространения нека- 
чественных данных через пару уровней, прежде чем привести к сбою, то вы- 
ясните, можно ли выделить ее раньше, улучшив проверку параметров в соот- 
ветствующих подпрограммах. (Подробнее о досрочном аварийном завершении 
и утверждениях см. соответственно в разделе “Принцип “поймал-отпустил” — 
только для ловли рыбы” и в разделе “Тема 25. Утвердительное программирова- 
ние” главы 4 “Прагматичная паранойя’.) 

Проверьте также, есть ли какие-нибудь другие места в исходном коде, ко- 
торые можно подозревать на проявление той же самой ошибки? Самое время 
найти их и устранить в них эту ошибку. Убедитесь, что чтобы ни случилось, 
если это произойдет вновь, вы будете об этом знать. 

Если устранение ошибки отнимает много времени, выясните, почему проис- 
ходит именно так и можно ли сделать что-нибудь, чтобы упростить устранение 
данной ошибки в следующий раз. Возможно, стоит встроить более совершенные 
перехватчики для тестирования или написать анализатор журнальных файлов. 
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Наконец, обсудите возникшее затруднение со всей командой, если програм- 
мная ошибка является результатом чьего-то неверного предположения. Ведь 
если заблуждается один человек, то могут заблуждаться и многие люди. Если 
вы сделаете все написанное выше, то можно надеяться, что в следующий раз 
возникающие программные ошибки удивят вас гораздо меньше. 


Контрольный СПИСОК ВОПРОСОВ ПО ОТЛАДКЕ 


Ниже перечислены вопросы, которые следует задавать в процессе отладки 
программ. 


е Является ли рассматриваемая неполадка непосредственным результатом 
или только симптомом скрытой программной ошибки? 


® Присутствует ли программная ошибка в используемом вами каркасе, опе- 
рационной системе или же в вашем коде? 


® Если бы вам довелось подробно объяснять возникшее затруднение колле- 
ге, то что бы вы ему сказали? 


ә Если подозрительный код проходит свои модульные тесты, то насколько 
они полноценны? Что произойдет, если выполнить эти тесты с конкрет- 
ными данными? 


® Существуют ли условия, при которых возникает данная программная 
ошибка, где-нибудь еще в системе? Находятся ли какие-нибудь другие 
скрытые ошибки, ожидающие возможности своего появления на свет? 


Другие разделы, связанные с данной темой 


ә Тема 24. Мертвые программы не лгут, глава 4 “Прагматичная паранойя”. 


Задача 


• Отладка — довольно трудная задача. 


ОА ИЛИН и А ВАНИЕ ИЛА А АОЛ Л ОРН МИ ОМАНА Пр ауе 117 нум КАЛИ, АО МАМ Зе УМОМ З ТосиаТЛИ ре ИН, ТА ВАД аә 07А или” МАН ПНА ЗАМ дань о ЛИЛ адор МАЛАКАСИ ео ДА рим ам 


МАаАнипулирОВАНИЕ ТЕКСТОМ 


Программисты-прагматики манипулируют текстом таким же образом, как и 
столяры, обрабатывающие древесину, придавая ей нужную форму. В предыду- 
щих разделах упоминался ряд конкретных инструментальных средств (оболоч- 
ки, редакторы, отладчики), которыми пользуются программисты-прагматики. 
Их можно сравнить со стамесками, пилами и рубанками, применяемыми для 
выполнения тех или иных столярных работ. Но иногда требуется выполнить 
преобразование, на которое неспособен основной набор инструментальных 
средств. И для этой цели требуется универсальное инструментальное средство 
манипулирования текстом. 
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В программировании языки манипулирования текстом выполняют те же 
функции, что и фрезерные станки в столярном деле. Это шумные, тяжелые инст- 
рументы, применяющие грубую силу. Стоит совершить ошибку, пользуясь ими, 
как вся заготовка разлетается на куски. Некоторые клянутся, что таким инстру- 
ментам нет места в их арсенале. Но в хороших руках как фрезерные станки, так 
и языки манипулирования текстом могут оказаться невероятно эффективными 
и универсальными инструментами. С их помощью можно быстро обрезать за- 
готовку, выполнить соединение и вырезать нужную форму. Но для овладения 
ими требуется время. 

Правда, существует целый ряд отличных языков манипулирования текс- 
том. Так, разработчики приложений для (Опіх, включая и пользователей тасО$, 
нередко любят использовать весь потенциал своих командных оболочек, под- 
крепленных такими инструментальными средствами, как амик и зеа. А те, кому 
больше нравятся структурированные инструментальные средства, могут отдать 
предпочтение таким языкам, как Руфоп или ВиБу. 

Такие языки являются важными базовыми технологиями. С их помощью 
можно быстро проработать утилиты и прототипные идеи, т.е. решить те задачи, 
на решение которых может потребоваться в пять-десять раз больше времени, 
чем с помощью обычных языков. А ведь такая многократная экономия време- 
ни очень важна для проведения экспериментов. В самом деле, потратить всего 
лишь 30 минут на опробование какой-нибудь безумной идеи намного привле- 
кательнее, чем израсходовать на это целых пять часов. Автоматизацией важных 
компонентов проекта вполне приемлемо заниматься целый рабочий день, но 
не целую неделю. В своей книге Практика программирования |КР99] Керниган 
и Пайк приводят пример создания одной и той же программы на пяти разных 
языках. Самой краткой оказалась версия на языке Рей (она состояла из 17 строк 
кода по сравнению со 150 строками кода на языке С). Используя Рей, можно 
манипулировать текстом, взаимодействовать с программами, обмениваться со- 
общениями по сети, вести веб-страницы, выполнять арифметические операции 
с произвольной точностью и писать программы, похожие на символические 
реплики Снупи’. 


Изучите язык манипулирования текстом 


Чтобы продемонстрировать применимость языков манипулирования текстом 
в обширных пределах, приведем ниже ряд примеров приложений, разработан- 


| Ѕпоору (любопытный) — персонаж в виде песика породы бигль из популярной серии 
комиксов Реапиѓѕ (Арахис), созданных американским художником Чарльзом М. Шульцем 
в 1950-е годы. — Примеч. пер. 
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ных нами на языках Кобу И Руіћоп и непосредственно связанных с написанием 
ЭТОЙ КНИГИ. 


® Составление книг. Система составления книг для издательства Ргартаќіс 
ВооКк$Ве! написана на языке Кобу. Авторы, редакторы, верстальщики и об- 
служивающий персонал пользуются задачами Каке для координации про- 
цессов составления текста в форматах РПЕ и электронных книг. 


• Включение и выделение исходного кода. Мы считаем очень важным про- 
верить сначала любой фрагмент кода, представленный на страницах книги, 
что и было проделано со всеми примерами кода из этой книги. Но, следуя 
принципу ОКУ (см. раздел “Тема 9. РКУ — пороки дублирования” главы 2 
“Прагматичный подход”), нам не хотелось бы копировать и вставлять 
строки кода из проверенных программ в текст книги. Ведь это означало бы 
дублирование кода и буквально гарантировало бы, что мы забудем обно- 
вить пример кода, когда соответствующая программа изменится. В некото- 
рых примерах отсутствует каркасный код, требующийся для компиляции 
и выполнения этих примеров, и поэтому мы обратились к услугам КаЪУ. 
В частности, для форматирования книги вызывается простой сценарий, 
извлекающий именованные сегменты из исходного файла, производится 
синтаксический анализ выделенного сегмента, выделяется синтаксис и по- 
лученный результат преобразуется в синтаксис применяемого языка ти- 
пографского набора. 


» Обновление веб-сайта. Для этой цели у нас имеется простой сценарий, 
частично составляющий книгу, извлекающий ее содержание, а затем об- 
новляющий его на странице нашего веб-сайта, посвященной данной книге. 
Кроме того, у нас имеется сценарий, извлекающий отдельные разделы кни- 
ги и выгружающий их на соответствующую страницу нашего веб-сайта в 
качестве образцов текста книги. 


• Включение уравнений. Для этой цели имеется сценарий, преобразующий 
разметку математических формул, набранных в редакторе ГаТеХ, в акку- 
ратно отформатированный текст. 


• Формирование предметного указателя. Большинство предметных указа- 
телей к книгам создаются как отдельные документы, что затрудняет их со- 
провождение при внесении изменений в книгу. Составленные нами пред- 
метные указатели размечены в тексте самой книги, а по сценарию КиБу они 
автоматически составляются и форматируются по отдельным статьям. 


Эти примеры можно продолжить. На практике издания Ргартаїіс Воокѕће]Ғ 
построены на манипулировании текстом. И если вы последуете нашему совету 
хранить данные в виде простого текста, то, пользуясь языками манипулирова- 
ния текстом, сможете извлечь для себя немало выгод. 
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Другие разделы, связанные с данной темой 
ө Тема 16. Сила простого текста. 


ә Тема 17. Игры в скорлупки. 


Упражнения 


11. Допустим, вы переписываете приложение, в котором раньше для конфи- 
гурирования использовался формат УАМГ. А теперь ваша организация 
перешла на стандартизированный формат ]$ОМ, и поэтому вам придется 
преобразовать целый ряд файлов с расширением .уат1 в файлы с расши- 
рением .ј ѕоп. Напишите с этой целью сценарий, принимающий каталог 
и преобразующий каждый файл с расширением . уат1 в файл с расшире- 
нием .)зоп таким образом, чтобы файл даёараѕе. уат1 стал, например, 
файлом дӢаёараѕе. ј ѕоп, а его содержимое — достоверно преобразовано в 
формат ]$ОМ. 


12. Допустим, ваша команда первоначально решила обозначать имена переменных 
в ГорбатомРегистре, а затем изменила свое коллективное решение, перей- 
дя на змеиный регистр. Напишите сценарий, просматривающий имена в 
ГорбатомРегистре во всех исходных файлах и сообщающий о них. 


13. Продолжая предыдущее упражнение, добавьте в написанный сценарий воз- 
можность автоматически изменять имена переменных в одном или несколь- 
ких исходных файлах. Не забудьте создать резервные копии оригиналов на 
тот случай, если что-то пойдет совсем не так, как предполагалось. 


Хе УА И дерут ПИ ИО т ТО ААА: Те ак: ИИ деи: СИИ ом вА леч ЗУТ АЛ Дети аи УГАТ ИМО А лечо М т ЖИ АЕ СИС МЛ МИА МНА беше Ар о АА 


ТЕХНИЧЕСКИЕ ДНЕВНИКИ 


Дэйв как-то работал в небольшой компании, производившей вычислитель- 
ную технику. Это означало, что ему пришлось работать вместе с инженерами- 
электронщиками, а иногда и с инженерами-механиками. Многие из них ходи- 
ли с бумажной записной книжкой и ручкой, прикрепленной к переплету такой 
книжки. И когда они общались с Дэйвом, то доставали свою записную книжку, 
открывали ее и что-то записывали в нее. 

В конечном счете Дэйв задал им вполне очевидный запрос, и оказалось, что 
они приучены вести технические дневники, т.е. своего рода журналы повседнев- 
ного учета, в которых они записывают все, что сделали, чему научились, наброс- 
ки идей, показания измерительных приборов, а по существу, все, что связано 
с их работой. Как только подобный дневник заполнялся, они надписывали на 
корешке интервалы дат ведения дневника и клали его на полку рядом с преды- 
дущими дневниками. Между инженерами могло даже возникнуть соревнование, 
чьи дневники займут больше места на полке. 
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Мы пользуемся техническими дневниками на совещаниях, чтобы записать в 
них то, над чем работаем, занести значения переменных во время отладки, ос- 
тавить памятки, что и где разместить, набросать самые безумные идеи, а иногда 
и просто рисовать машинально “чертиков”?. 


Техническим дневникам присущи следующие достоинства. 


• Они более надежны, чем память. Так, если вас спросят: “Как называлась 
компания, к которой вы обращались на прошлой неделе по поводу энер- 
госнабжения?” вы, пролистав свой дневник на несколько страниц назад, 
сможете сообщить название и номер телефона данной компании. 


® В них есть место для хранения идей, которые не сразу оказываются при- 
годными для решения насущной задачи. Подобным образом вы можете и 
дальше сосредоточиться на том, что делаете, зная, что ваша замечательная 
идея не будет забыта. 


® Они действуют подобно резиновому утенку, описанному ранее в разделе 
“Метод резинового утенка”. Как только вы перестанете что-то записывать 
в дневник, ваш ум может переключиться на другие мысли, как если бы во 
время беседы с кем-нибудь у вас появилась возможность поразмыслить 
над сказанным. Вы можете начать запись в дневнике и вдруг осознать, что 
сделанная только что запись просто неверна. 


У технических дневников имеется еще одно преимущество. Время от време- 
ни вы можете просматривать свои записи, сделанные много лет назад, вспоми- 
ная людей, проекты, ужасные одежды и прически. 

Итак, старайтесь вести свой технический дневник, пользуясь бумажной за- 
писной книжкой, а не файлом или вики-страницей, поскольку в записывающем 
действии есть нечто особенное по сравнению с набором текста. Через месяц 
ведения такого дневника вы почувствует все его преимущества, перечисленные 
выше. Во всяком случае, это упростит написание воспоминаний, когда вы раз- 
богатеете и добьетесь известности. 


Другие разделы, связанные с данной темой 


® Тема 6. Ваш багаж знаний, глава 1 “Философия прагматизма”. 


• Тема 37. Прислушивайтесь к своим инстинктам, глава 7 “По ходу кодиро- 
» 
вания”. 


8 Имеется ряд свидетельств, что машинальное рисование “чертиков” и прочих каракулей 
помогает сосредоточиться и совершенствует познавательные навыки. Примеры тому см. 
в книге И/Йа! доеѕ доо4Ййих до? [Апа10]. 


[ЛАВА 4 


_ _ ПРАГМАТИЧНАЯ ПАРАНОЙЯ 


Написать идеальную программу нельзя 


Задевает? А не должно бы. Примите этот совет как аксиому, оценив и при- 
ветствовав его, поскольку идеального программного обеспечения не существует. 
Никому за краткую историю вычислительной техники еще не удавалось напи- 
сать идеальную программу, и вы вряд ли будете первым. Если же вы не примете 
это как данность, то в конечном счете потратите зря время и силы, преследуя 
неосуществимую мечту. Так как же программисту-прагматику извлечь выгоду 
из этой гнетущей реальности? Именно данной теме и посвящена эта глава. 

Каждый считает, что он является самым лучшим водителем на свете, а всем 
остальным далеко до такого лихача, проскакивающего запрещающие знаки, ла- 
вирующего между дорожными полосами, не подавая сигналы поворота, наби- 
рающего текст сообщений на мобильном телефоне и вообще живущего не по 
правилам. А мы вот ездим осторожно, остерегаясь беды еще до того, как она 
случится, предвидя неожиданное и никогда не ставя себя в такое положение, из 
которого нельзя выпутаться. 

Аналогия с программированием вполне очевидна. Мы постоянно имеем дело 
с чужим кодом, который может и не соответствовать высоким стандартам, а 
также с входными данными, которые могут и не быть достоверными. Поэтому 
мы приучены программировать, будучи начеку. И если у нас возникает какое- 
нибудь сомнение, то мы проверяем всю данную нам информацию. Для выявле- 
ния некачественных данных мы пользуемся проверками, не доверяя данным, 
получаемым от потенциальных атакующих злоумышленников или троллей. Мы 
выполняем проверку на согласованность, накладываем ограничения на столбцы 
в таблице базы данных и, в общем, чувствуем себя прекрасно. 

Но программист-прагматик идет дальше, не доверяя даже себе. Отлично зная, 
что никому не дано написать идеальный код, включая и нас самих, программис- 
ты-прагматики выстраивают бастионы защиты против собственных ошибок. 
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Первая защитная мера описывается в разделе “Проектирование по контракту’, 
когда клиенты и поставщики должны согласовать права и обязанности. 

Затем в разделе “Мертвые программы не лгут” поясняется, что обработка 
программных ошибок не наносит никакого вреда. Поэтому следует стараться 
производить проверки как можно чаще и прерывать программу, если дело при- 
мет скверный оборот. А в разделе “Утвердительное программирование” опи- 
сывается простой метод оперативной проверки, который состоит в написании 
кода, активно проверяющего предположения программиста. 

По мере того как ваша программа становится все более динамичной, вы об- 
наруживаете, что манипулируете системными ресурсами (оперативной памятью, 
файлами, устройствами и т.п.), словно жонглируя шарами. Поэтому в разделе 
“Как сбалансировать ресурсы” предлагаются способы не потерять ни одного 
такого шара. А самое главное — продвигаться к цели мелкими шагами, чтобы 
не свалиться в пропасть с края утеса, как поясняется в разделе “Не опережайте 
свет фар вашего автомобиля”. 

В мире несовершенных систем, нелепых временных шкал, забавных инстру- 
ментов и невыполнимых требований приходится действовать осторожно. Как 
однажды сказал известный кинорежиссер Вуди Аллен: “Когда все фактически 
строят вам козни, единственная хорошая мысль — это паранойя”. 


Я О О О 


ПРОЕКТИРОВАНИЕ ПО КОНТРАКТУ 


“Ничто так не поражает людей, 
как здравый смысл и откровенность”. 


Ральф Уолдо Эмерсон!, Очерки (Ебзау5) 


Обращаться с вычислительными системами нелегко, а иметь дело с людьми 
еще труднее. Но как биологический вид мы с давних пор выясняли вопросы 
человеческих взаимоотношений. Некоторые решения, к которым мы пришли 
за последние несколько тысячелетий, могут пригодиться и для написания про- 
грамм. И одним из самых лучших решений, гарантирующих прямоту отноше- 
ний, является контракт. Контракт определяет права и обязанности обеих за- 
ключивших его сторон. Кроме того, в нем предусмотрено соглашение сторон, 
касающееся последствий, если одна из них не выполнит контракт. 

Так, вы могли заключить контракт о найме, в котором указано сколько часов 
вы должны работать, а также правила, которые вы обязаны соблюдать. В свою 
очередь, работодатель платит вам зарплату и остальные надбавки. Если каждая 
сторона выполняет свои обязательства, то выигрывают от этого все. 


1 ВајрЬ У/ао Етегѕоп — американский эссеист, поэт, философ, пастор, общественный 
деятель ХІХ века. — Примеч. пер. 
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Идея контракта используется во всем мире (формально или неформально) 
с целью помочь людям наладить взаимоотношения. А может ли тот же самый 
принцип оказать помощь в налаживании взаимодействий между программны- 
ми модулями? Да, может. 


ПРИНЦИП ПРОЕКТИРОВАНИЯ ПО КОНТРАКТУ 


Бертран Мейер (Вейгапа Меуег; ОБзес!-Опетей Ѕоўимате Сопѕітисіоп [Меу97]) 
разработал принцип проектирования по контракту для языка ЕШеР. Это про- 
стая, но эффективная методика, направленная на документирование (и согласо- 
вание) прав и обязанностей программных модулей, чтобы обеспечить правиль- 
ность программы. А что такое правильная программа? Это такая программа, 
которая выполняет только то, что от нее требуется, — ни больше и ни меньше. 
Документирование и верификация такого требования и составляет саму суть 
проектирования по контракту (Оезвп Бу Сопігасі, ОВС). 

Каждая функция и метод в программной системе выполняет какое-то дей- 
ствие. Прежде чем начать это действие, функция может предполагать какое-то 
состояние окружающего мира, а по завершении она может сделать заявление о 
состоянии окружающего мира. Эти предположения и требования Мейер описы- 
вает следующим образом. 


® Предусловия. Это требования подпрограммы, которые определяют, что 
должно быть истинным для ее вызова. Подпрограмма вообще не должна 
вызываться, если ее предусловия будут нарушены. На вызывающий код 
возлагается ответственность за передачу качественных данных (см. врезку 
“Кто несет ответственность” далее в этой главе). 


е Постусловия. Это состояние окружающего мира по завершении подпро- 
граммы, т.е. то, что ею гарантируется. Наличие постусловия у подпрограм- 
мы подразумевает, что она непременно завершится, а следовательно, бес- 
конечные циклы не допускаются. 


® Инварианты класса. Класс гарантирует, что данное условие для вызыва- 
ющего кода всегда истинно. В процессе внутренней обработки в подпро- 
грамме инвариант может и не соблюдаться, но к моменту выхода из под- 
программы и передачи управления вызывающему коду инвариант должен 
быть непременно истинным. (Следует, однако, иметь в виду, что класс не 
может предоставить неограниченный доступ для записи к любому члену 
данных, принимающему участие в инварианте.) 


Таким образом, контракт между подпрограммой и любым потенциально вы- 
зывающим кодом может быть составлен следующим образом. 


2 Частично на основании прежних трудов Дейкстры (ЮіјКѕїта), Флойда (Ноу4), Хоара 
(Ноаге), Вирта (Мікћ) и других. 
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® Если все предусловия подпрограммы удовлетворяются вызывающим ко- 
дом, то подпрограмма гарантирует истинность всех постусловий и инва- 
риантов при своем завершении. 


Если же одна из сторон контракта не выполняет его условия, то вызывается 
(предварительно согласованное) средство защиты нарушенных прав, например: 
возникает исключение или прерывание программы. Что бы ни случилось, не 
сомневайтесь, что несоблюдение условий контракта считается программной 
ошибкой. Нет никакой гарантии, что этого вообще не произойдет, именно поэ- 
тому предусловия и нельзя использовать для выполнения таких операций, как 
проверка вводимых пользователем данных на достоверность. 

В одних языках эти принципы поддерживаются лучше, чем в других. Напри- 
мер, в языке С]оаге поддерживаются предусловия и постусловия, а также более 
обширный инструментарий, предоставляемый по спецификации. Ниже приве- 
ден пример функции для открытия вклада в банке с помощью пред- и пост- 
условий. 


(4еЁп ассері-аероѕі [ассоцпі-іа атоцпЕ] 


{ :рге [ (> апоопіё 0.00) 
(ассоипЕ-ореп? ассоџпіё-іа) ] 
:розЕ [ (сопЕа1п$? (ассоџпі-їгапѕасіёіопѕ ассоцп*-1а) $%) ] } 


"Ассере а Яероѕії апа гебагп Ве пем ёгапѕасііоп іа" 
;; Здесь выполняется остальная обработка... 

;; Возвратить вновь созданную транзакцию: 
(сгеаЁе-ЕгапзасЕ1оп ассоџпі-іа :аероѕіє атоцп*)) 


Для функции ассерЕ-Черо$1* () здесь заданы два предусловия. Первое со- 
стоит в том, что сумма вклада должна быть больше нуля, а второе — в том, что 
счет должен быть открыт и действителен. Последнее определяется путем вызова 
функции ассоипЕ-ореп? (). Имеется также следующее постусловие: функция 
гарантирует, что новая транзакция (возврат из данной функции значения, пред- 
ставленного в процентах "%") может находиться среди прочих транзакций для 
данного счета. 

Если вызвать функцию ассері-ӣероѕії () с положительной суммой для 
открытия вклада и действительным счетом в банке, то она создаст далее тран- 
закцию подходящего типа и выполнит всю остальную требующуюся обработ- 
ку. Но если в программе имеется ошибка и данной функции каким-то образом 
передана отрицательная сумма для открытия вклада, то во время выполнения 
возникнет следующее исключение: 


Ехсер®1оп іп їһгеаа "таіп"... 
Сачзеа ру: јаха. 1апдо.АѕзѕегііопЕггог: 
Аѕѕегі Ғаі1еа: (> атоппЕ 0.0) 


Кроме того, данная функция требует, чтобы указанный счет был открыт и 
действителен. В противном случае появится такое исключение: 
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Ехсерііоп іп &ПгеаА "тат"... 
Сацѕеа Бу: јауа. 1апа.АѕѕегііопЕггог: 
Аѕѕегі Ғаі1еа: (ассоџпі-ореп? ассооцпі-іа) 


В других языках имеются средства, дающие неплохой результат, несмотря на 
то, что они не относятся непосредственно к проектированию по контракту. На- 
пример, в языке ЕЙйхи применяются операторы защиты для диспетчеризации 
вызовов функции по нескольким имеющимся ее телам: 


деЕтодо1е рероѕіізѕ ао 
её ассері дероѕії (ассоџпі 14, атоопё) мћеп (апоцпЕ > 100000) до 
# Вызвать диспетчер! 
епа 
её ассері дероѕії (ассоџпі 14, амоип®) мћеп (атоцпі > 10000) до 
# Дополнительные федеральные требования для отчетности 
# Здесь выполняется некоторая обработка... 
епа 
ЧеЕ ассері адероѕії (ассоопі іа, атоџпі) мћеп (атоцпе > 0) ао 
# Здесь выполняется некоторая обработка... 
епа 
епа 


В данном случае вызов функции ассерї Яероѕії () с крупной суммой мо- 
жет потребовать дополнительных шагов и обработки. Но если попытаться вы- 
звать данную функцию с суммой, меньшей или равной нулю, то возникнет при- 
веденное ниже исключение, которое извещает, что сделать такой вклад нельзя. 


** (ЕцпсііопС1ІаџоѕеЕггог) по Ғиопсїіоп с1Іаизѕе 
пасһіпд іп рероѕієѕ.ассерё Яероѕії/2 


Это лучше, чем просто проверять входные данные. В данном случае функцию 
ассерї Яероѕії () просто нельзя вызвать, если ее аргументы указаны вне за- 
данных пределов. 


Проектируйте по контракту 


В разделе “Тема 10. Ортогональность” главы 2 “Прагматичный подход” мы 
рекомендовали писать “скромный” код. А здесь акцент делается на “ленивый” 
код, предусматривающий строго относиться к тому, что принимается, прежде 
чем начинать что-нибудь делать, а также обещать как можно меньше. Не следу- 
ет, однако, забывать, что если в контракте вы согласились принимать все, что 
угодно, и наобещали на выходе целый мир, то для соблюдения такого контракта 
вам придется написать немало кода! При программировании на любом языке, 
будь то функциональном, объектно-ориентированном или процедурном, проек- 
тирование по контракту заставляет вас думать. 
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Инварианты класса и функциональные языки 


Все дело в названиях. Язык ЕіЌе! является объектно-ориентированным, и по- 
этому Мейер назвал данное понятие “инвариантом класса”. Но на самом деле это 
более общее понятие, обозначающее состояние. В объектно-ориентированном 
языке состояние связано с экземплярами классов, но ведь состояние имеется и в 
других языках. Так, в функциональном языке состояние, как правило, передает- 
ся функции и принимается обновленным в результате ее выполнения. Понятия 


инвариантов оказываются столь же полезными и в этих обстоятельствах. 


_ ПРОЕКТИРОВАНИЕ ПО КОНТРАКТУ И РАЗРАБОТКА НА ОСНОВЕ ТЕСТИРОВАНИЯ — 


Есть ли потребность в проектировании по контракту там, где разработчики 
практикуют модульное тестирование, разработку на основе тестирования 
(Теѕ-Огімеп Оеуеіортепї — ТОО), тестирование на основе свойств или за- 
щитное программирование? Конечно, есть. 


Проектирование по контракту и тестирование — это разные подходы к 
более обширной теме правильности программ. Оба подхода ценны и при- 
годны в разных ситуациях. Проектирование по контракту дает ряд преиму- 
ществ по сравнению с иными подходами к тестированию. 


Оно не требует никакой подготовки или имитации. 


Определяет параметры удачного или неудачного исхода во всех случа- 
ях, тогда как тестирование может быть одновременно нацелено лишь на 
один конкретный случай. 


Разработка на основе тестирования и другие разновидности тестирова- 
ния происходят в цикле сборки лишь во время тестирования, а проекти- 
рование по контракту и утверждения — постоянно: во время проектиро- 
вания, разработки, развертывания и сопровождения. 


Разработка на основе тестирования не сосредоточена на проверке внут- 
ренних инвариантов в тестируемом коде, а действует в большей степени 
по принципу “черного ящика" для проверки открытого интерфейса. 


Проектирование по контракту более эффективно и соблюдает принцип 
ОВУ точнее, чем защитное программирование, где все должны проверить 
данные на достоверность, если этого никто больше не делает. 


Разработка на основе тестирования — отличная методика, но, как и мно- 
гие другие методики разработки, она может привести к сосредоточению на 
удачном пути, а не на реальном мире, где полно некачественных данных, 
плохих исполнителей, неудачных версий и скверных спецификаций. 
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РЕАЛИЗАЦИЯ ПРОЕКТИРОВАНИЯ ПО КОНТРАКТУ 


Простое перечисление пределов области входных значений, граничных ус- 
ловий и того, что подпрограмма обещает (а еще важнее то, что она не обещает) 
предоставить, перед тем, как писать код, — это огромный шаг вперед в разра- 
ботке более качественного программного обеспечения. Не сформулировав все 
эти условия, вы, по существу, возвращаетесь к программированию по совпадению, 
рассматриваемому в разделе “Тема 38. Программирование по совпадению” гла- 
вы 7 “По ходу кодирования”. Именно с этого начинаются, этим заканчиваются 
и терпят крах многие проекты. 

В тех языках, где проектирование по контракту в исходном тексте не подде- 
рживается, это может быть все, чего удастся достичь, но и это не так уж плохо. 
Ведь проектирование по контракту — это всего лишь методика проектирова- 
ния. Даже не прибегая к автоматической проверке, можно внедрить контракт в 
исходный текст в виде комментариев или как модульные тесты и, тем не менее, 
извлечь из этого весьма реальную выгоду. 


Утверждения 


Несмотря на то что документирование подобных предположений служит хо- 
рошим началом, можно извлечь еще большую выгоду, заставив компилятор авто- 
матически проверять контракт. Такую проверку можно частично сэмулировать в 
некоторых языках с помощью утверждений (аѕѕегііопѕ) — проверки логических 
условий во время выполнения (см. далее раздел “Тема 25. Утвердительное про- 
граммирование”). А почему лишь частично? Нельзя ли с помощью утверждений 
добиться всего, на что только способно проектирование по контракту? 

К сожалению, нельзя. Прежде всего, в объектно-ориентированных языках 
может не поддерживаться распространение утверждений по иерархии наследо- 
вания. Это означает, что если переопределить в базовом классе метод, имеющий 
контракт, то утверждения, реализующие этот контракт, не будут корректно вы- 
званы, если только не продублировать их вручную в новом коде. И нужно не за- 
быть вызвать инвариант класса (и все инварианты базового класса) вручную пе- 
ред выходом из каждого метода. Главная трудность состоит в том, что контракт 
не выполняется автоматически. А в других средах исключения, генерируемые из 
утверждений, составленных в стиле проектирования по контракту, могут быть 
отключены глобально или полностью проигнорированы исходным текстом. 

Кроме того, не предусмотрено такое понятие, как “старые” значения, т.е. зна- 
чения, которые существовали на момент входа в метод. Если вы пользуетесь 
утверждениями для проверки контрактов, то должны ввести код в предусловие, 
чтобы сохранить любую информацию, которая потребуется в постусловии, если 
язык вообще допускает такое. Так, в языке ЕШЕ|, где, собственно, зародилось 
проектирование по контракту, для этой цели достаточно воспользоваться вы- 
ражением о1а. 
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Наконец, обычные системы времени выполнения и библиотеки не предна- 
значены для поддержки контрактов, поэтому подобные вызовы не проверяются. 
Это немалая потеря, поскольку на границе между прикладным кодом и приме- 
няемыми в нем библиотеками обнаруживается большинство затруднений (под- 
робнее об этом — далее в разделе “Тема 24. Мертвые программы не лгут”). 


ПРОЕКТИРОВАНИЕ ПО КОНТРАКТУ И АВАРИЙНОЕ ЗАВЕРШЕНИЕ 


Проектирование по контракту изящно вписывается в понятие досрочного 
аварийного завершения (см. далее в разделе “Тема 24. Мертвые программы не 
лгут”). Используя механизм утверждений или проектирования по контракту для 
проверки достоверности предусловий, постусловий и инвариантов, можно до- 
биться досрочного аварийного завершения программы и сообщить более точ- 
ные сведения о возникшей неполадке. 

Допустим, имеется метод, вычисляющий квадратные корни. Этому методу тре- 
буется предусловие проектирования по контракту, ограничивающее область его 
действия положительными числами. Если передать данному методу отрицатель- 
ное значение параметра заг\ в тех языках, где поддерживается проектирования 
по контракту, то в конечном итоге будет получено сообщение об ошибке напо- 
добие ѕагі ага мизе ре роѕіѓіуе (аргумент для извлечения квадратного 
корня должен быть положительным) вместе с результатами трассировки стека. 

Это, конечно, лучше, чем альтернатива, имеющаяся в других языках наподо- 
бие Јауа, Си С++, где в результате передачи методу отрицательного значения 
параметра ѕагі возвращается специальное значение Мам (не число). И если 
некоторое время спустя попытаться выполнить в программе какие-нибудь ма- 
тематические операции над значением Мам, то в итоге будут получены совсем 
неожиданные результаты. 

Намного проще найти и диагностировать неполадку, досрочно достигнув 
аварийного завершения в месте возникновения этой неполадки. 


(СЕМАНТИЧЕСКИЕ ИНВАРИАНТЫ 


Семантические инварианты могут быть использованы для выражения не- 
изменных требований, нечто наподобие “философского контракта’. Нам как-то 
пришлось разрабатывать программный коммутатор транзакций по дебетовым 
банковским карточкам. Главное требование состояло в том, чтобы пользова- 
тель дебетовой карточки не мог дважды выполнить одну и ту же транзакцию на 
своем счету. Иными словами, какого бы рода режим отказа ни возник, ошибка 
должна вызывать запрет обработки транзакции, но только не обработку дуб- 
лированной транзакции. Это простое правило, вытекающее непосредственно 
из требований, оказывается очень полезным, когда приходится разбираться со 
сложными случаями устранения ошибок. И оно направляет на путь подробного 
проектирования и реализации во многих областях. 
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—_ Кто НЕСЕТ ответственность о 


Кто же отвечает за проверку предусловия: вызывающий код или вызыва- 
емая подпрограмма? Если проектирования по контракту реализуется как 
часть языка, то за такую проверку не отвечает ни то ни другое. Ведь предус- 
ловие проверяется подспудно после того, как подпрограмма будет вызвана 
в вызывающем коде, но до входа в саму подпрограмму. Так, если требуется 
выполнить явную проверку параметров, это должно быть сделано в вызы- 
вающем коде, поскольку самой подпрограмме вообще недоступны пара- 
метры, нарушающие предусловие. (В тех языках, где отсутствует встроенная 
поддержка проектирования по контракту, чтобы проверить подобные ут- 
верждения, вызываемая подпрограмма должна иметь для этой цели преам- 
булу и/или заключительную часть.) 


Рассмотрим в качестве примера программу, вводящую число с консоли, из- 
влекающую из него квадратный корень с помощью функции заг* () и вы- 
водящую результат. У функции заг* () имеется следующее предусловие: ее 
аргумент не должен быть отрицательным. Если пользователь введет в кон- 
соли отрицательное число, то вызывающий код обязан принять меры, чтобы 
оно не было передано функции заг* (). У этого вызывающего кода имеется 
много вариантов действий: прервать выполнение, выдать предупреждение 
и потребовать ввести другое число в консоли, сделать число положитель- 
ным, или добавить к результату, возвращаемому функцией зак (), символ 
мнимой единицы (7. Но какой бы выбор ни был сделан, это совершенно не 
касается самой функции заг* (). 


Выражая область действия функции заг* (), извлекающей квадратный ко- 
рень, в ее предусловии, вы фактически переносите бремя ответственности 
за правильность на вызывающий код, где ему и место. И тогда вы можете 
благополучно проектировать функцию зах* (), твердо зная, что ее вход- 
ные данные окажутся в пределах, заданных контрактом. 


Ни в коем случае не путайте требования, являющиеся фиксированными и 
неизменными правилами, с требованиями, представляющими собой лишь стра- 
тегии, которые могут измениться вместе с новым режимом управления. Именно 
поэтому мы пользуемся здесь термином семантические инварианты, поскольку 
ему принадлежит центральное место в определении самой сути предмета, и он 
не должен подчиняться прихотям стратегии, которой в большей степени отве- 
чают более динамичные бизнес-правила. 

Когда вы обнаруживаете требование, которое может уточняться, примите 
меры, чтобы оно стало хорошо известной частью любой составляемой докумен- 
тации, будь то маркированный список в документе требований, который под- 
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писывается в трех экземплярах, или же крупная заметка на общей белой доске, 
видимой всем. Попробуйте сформулировать это требование ясно и однозначно. 
Так, если вернуться к примеру с дебетовыми карточками, то такое требование 
можно было бы сформулировать следующим образом: 


Ошибка — в пользу потребителя. 


Это ясная, краткая, однозначная формулировка, применимая на самых раз- 
ных участках системы. Это наш контракт со всеми пользователями системы и 
наша гарантия ее поведения. 


ДинлдмичеСъкие КОНТРАКТЫ И АГЕНТЫ 


До сих пор речь шла о контрактах как фиксированных, неизменяемых специ- 
фикациях. Но в области автономных агентов это совсем не обязательно должно 
быть именно так. По определению автономные агенты вольны отвергать те за- 
просы, которые они не желают принимать во внимание. Они вольны согласовы- 
вать контракт заново, заявляя: “Я не могу это предоставить, но если вы дадите 
мне то и это, тогда я мог бы предоставить вам что-нибудь другое”. 

Безусловно, любая система, опирающаяся на технологию агентов, находится 
в решающей зависимости от договорных отношений, даже если они генериру- 
ются динамически. 

Представьте: при достаточном количестве компонентов и агентов, способных 
согласовывать между собой контракты, чтобы достичь поставленной цели, мы 
могли бы просто дать программному обеспечению возможность разрешить кри- 
зис его производительности вместо нас. 

Но если мы не можем пользоваться контрактами вручную, то не сможем 
воспользоваться ими и автоматически. Поэтому в следующий раз, когда будете 
проектировать какое-нибудь программное обеспечение, спроектируйте для него 
контракт. 


Другие разделы, связанные с данной темой 


® Тема 24. Мертвые программы не лгут. 


Тема 25. Утвердительное программирование. 


Тема 38. Программирование по совпадению, глава 7 “По ходу кодирования”. 
е Тема 42. Тестирование на основе свойств, глава 7 “По ходу кодирования”. 


ө Тема 43. Будьте осторожны, глава 7 “По ходу кодирования”. 


е 


Тема 45. Западня требований, глава 8 “До начала проекта” 
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Задачи 


® Рассмотрите следующие вопросы для размышления: если проектирова- 
ние по контракту настолько эффективно, то почему оно не находит более 
широкого применения? Трудно ли сформулировать контракт? Заставляет 
ли это вас задуматься над теми вопросами, которые вы иначе проигнори- 
ровали бы? Заставляет ли это вас вообще ДУМАТЬ?! Очевидно, что это 
опасное инструментальное средство! 


Упражнения 


14. Разработайте интерфейс для кухонного блендера. В конечном итоге это дол- 
жен быть ориентированный на веб и Интернет вещей блендер, но пока что 
требуется лишь интерфейс для управления им. В нем должны быть средства 
для установки десяти скоростей, причем 0 означает выключение блендера. 
Работать с блендером вхолостую нельзя, а его скорость можно изменять 
лишь по очереди и на единицу, т.е. от 0 до |1 иот 1 до 2, но не от 0 до 2. 


Ниже приведены соответствующие методы. Добавьте соответствующие пред- 
и постусловия и инвариант. 

іпі адеїбрееа () 

уоіа ѕеібрееа (ілі х) 

Боо1еап 1іѕЕц11 () 


уоіа #111 () 
уоіа епрѓу () 


15. Сколько всего чисел в ряду 0, 5, 10, 15, ..., 100? 


ИТМО ут РАМЕ ЕТС, ЧАВО УНАА ААТА КИ А РАМО КДИ реу ату ТАМУ ТАЛТ а о ЗНД Пир МЕХ л ме. ЧАМ елт РАМЫ АЗ ИУ А Ф ТАОМ АГАЎ ЛАЗ ТЫГУУ ООА ГТУ ВААС ам РТН ЧОРОЛОР ЗА Вечара ара ТАМА 


| МЕРТВЫЕ ПРОГРАММЫ НЕ ЛГУТ 


Приходилось ли вам замечать, что иногда другие люди могут раньше вас об- 
наружить, что с вами что-то не так? То же самое случается и с кодом. Так, если 
с одной из ваших программ случится что-то неладное, то неполадка иногда вы- 
является в сторонней библиотеке или каркасе. Причина может быть, например, 
в том, что в библиотечную функцию было передано пустое значение пі1 или 
же пустой список. Возможно, в хеше отсутствует ключ или значение, которое, 
как нам казалось, содержит хеш, на самом деле содержит список. А может быть, 
в сети или файловой системе произошла ошибка, которая не была перехвачена, 
в результате чего были получены пустые или испорченные данные. Логическая 
ошибка, совершенная пару миллионов операций назад, означает, что в селекторе 
оператора сазе больше не ожидается значение 1, 2 или 3, и поэтому неожидан- 
но происходит переход к ветви діеҒаџ1+. И это еще одна причина, по которой в 
каждой инструкции $\1ЕсВ непременно должна присутствовать ветвь деѓац1 
на тот случай, если произойдет нечто “невозможное”. 
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Очень легко впасть в ошибку “этого не может произойти”. Большинству из 
нас приходилось писать код, в котором не проверялось успешное закрытие фай- 
ла и надлежащее написание оператора трассировки. И при прочих равных ус- 
ловиях нам это, вероятнее всего, было не нужно, поскольку мы считали, что 
наш код не потерпит крах при любых нормальных условиях. Но мы используем 
защитное программирование. В частности, проверяем данные на достоверность, 
рабочий код — на работоспособность, а версии загруженных зависимостей — 
на правильность. 

Все ошибки дают какую-то информацию для размышления. Можно, конеч- 
но, убедить себя, что ошибка не случится и просто проигнорировать ее. Вместо 
этого программисты-прагматики говорят себе: если возникла ошибка, значит, 
произошло что-то очень и очень скверное. Поэтому не забывайте читать все 
эти отвратительные сообщения об ошибках (см. раздел “Программист в чужой 
стране” главы 3). 


ПРИНЦИП “ПОЙМАЛ-—ОТПУСТИЛ” — ТОЛЬКО ДЛЯ ЛОВЛИ РЫБЫ 


Некоторые разработчики считают хорошим стилем программирования пере- 
хватывать все исключения или восстанавливать нормальную работу програм- 
мы после их возникновения, а также повторно генерировать их после вывода 
какого-нибудь сообщения. В их коде можно найти немало таких мест, как в 
приведенном ниже фрагменте, где пустой оператор гаі ѕе повторно генерирует 
текущее исключение. 

гу ао 

ада ѕсоге фо _Боага (ѕсоге); 
гезсие Іпуа114Ѕсоге 
Іоддег.еггог ("Сап'+ ааа іпуа1іа ѕсоге. Ехіїіпа"); 
га1зе 
гезсие Воагабегуегроип 
Годаег.еггохг ("Сап'ї ааа ѕсоге: роага 1$ аомп. Ех1®1п9"); 
га1зе 
гезсие бЅіа1еТгапѕасііоп 
Іоддег.еггог ("Сап' ааа зсоге: ѕёа1е &гапзас®1оп. Ехісіпд"); 
гаізѕе 

епа 


А вот что написал бы программист-прагматик: 


ааа ѕсоге ёо Боага (ѕсоге); 


Мы предпочитаем именно такой стиль по двум причинам. Во-первых, при- 
кладной код не затмевается обработкой ошибок. Во-вторых, что, вероятно, еще 
важнее, прикладной код оказывается менее связанным. В приведенном выше 
многословном примере приходится перечислять каждое исключение, которое 
может быть сгенерировано в методе ааа ѕсоге іо роага (). Если автор это- 
го метода введет еще одно исключение, то его код едва заметно устареет. А в 
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более прагматичном втором примере новое исключение распространяется ав- 
томатически. 


Пользуйтесь досрочным аварийным завершением программы 


АВАРИЙНОЕ ЗАВЕРШЕНИЕ ВМЕСТО ОТПРАВКИ НА СВАЛКУ 


Одно из преимуществ как можно более раннего выявления неполадок состо- 
ит в возможности досрочного аварийного завершения. И зачастую это самое 
лучшее, что можно делать. В качестве альтернативы можно продолжить, записав 
испорченные данные в некоторую актуальную базу данных или дав стиральной 
машине команду на двадцатом по счету цикле вращения ее барабана с бельем. 

Именно такой принцип поддерживается в языках Егапе и ЕЙйх!. Джо Армс- 
тронг, изобретатель языка Ейап? и автор книги Ргортаттіпу ЕғІапр: Зойате јот 
а Сопситтепі Уотіа [Агт07], часто говорил следующее: “Защитное программи- 
рование — это напрасная трата времени. Допускайте аварийное завершение!” 
В таких средах предусматривается, что программы могут отказывать, но от- 
каз находится под управлением супервизора, отвечающего за выполнение кода 
и знающего, что именно следует делать, если код откажет. К подобным мерам 
относится очистка после сбоя, перезапуск кода и т.д. А что, если откажет сам 
супервизор? Этим событием управляет его собственный супервизор, что приво- 
дит к архитектуре, состоящей из деревьев супервизоров. Такая методика довольно 
эффективна и способствует применению упомянутых выше языков в высокона- 
дежных, отказоустойчивых системах. 

В других средах простой выход из работающей программы может оказать- 
ся неприемлемым. Ведь в ней могли быть затребованы ресурсы, которые могут 
быть и не освобождены. А возможно, придется написать протокольные сообще- 
ния, очистить открытые транзакции или организовать взаимодействие с други- 
ми процессами. 

Тем не менее основной принцип остается прежним: если в прикладном коде 
обнаруживается, что произошло нечто, предполагавшееся невозможным, такой 
код больше не считается жизнеспособным. И все, что в таком коде делается 
дальше, становится подозрительным, а следовательно, его выполнение следует 
прервать как можно скорее. Мертвая программа, как правило, наносит намного 
меньше вреда, чем испорченная. 


Другие разделы, связанные с данной темой 
ә Тема 20. Отладка, глава 3 “Основные инструментальные средства". 


® Тема 23. Проектирование по контракту. 
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Тема 25. Утвердительное программирование. 


Тема 26. Как сбалансировать ресурсы. 


Тема 43. Будьте осторожны, глава 7 “По ходу кодирования”. 


РЫЯ ИЕН ВА А #2 ЕЛНЕСАЕРЛИАЛЕЕНОЧЬИ СЕЕ кже ч пе д жд У Э о в мор зо пам ь 5 


УтВЕРДИТЕЛЬНОЕ ПРОГРАММИРОВАНИЕ 


“В самобичевании есть свое наслаждение. 
И когда мы виним себя сами, то чувствуем, 
что никто другой не вправе винить нас”. 


Оскар Уайльд, Портрет Дориана Грея 


По-видимому, есть такая мантра, которую каждый программист должен за- 
помнить, едва начав свою карьеру. Это основополагающий постулат, убеждение, 
которое мы учимся применять к требованиям, проектам, исходному коду, ком- 
ментариям и практически ко всему, что мы делаем. И он гласит: 


Это никогда не может случиться... 


Примерами тому служат следующие рассуждения: “Это приложение никог- 
да не будет применяться за рубежом, так зачем его интернационализировать?”, 
“Переменная соџпі не может принимать отрицательное значение” или “Прото- 
колирование не может дать сбой”. Старайтесь избегать в своей практике подоб- 
ного самообольщения, особенно во время программирования. 


Пользуйтесь утверждениями, чтобы предотвратить невозможное 


Всякий раз, когда вы ловите себя на мысли “но этого, конечно, никогда не 
сможет случиться’, вводите код для ее проверки. И сделать это проще всего с 
помощью утверждений. В реализациях многих языков можно обнаружить неко- 
торую форму утверждений в виде оператора аѕѕегё, где проверяется логичес- 
кое условие”. Такие проверки могут оказаться неоценимыми. Так, если параметр 
или результат вообще не должен быть пустым (по11), его следует проверить 
явным образом, как показано ниже. 


аѕѕегі (геѕиії != пи11); 


3 В языках Си С++ утверждения обычно реализуются в виде макрокоманд, а в языке Јауа 
они запрещены по умолчанию. Чтобы разрешить их, следует вызвать виртуальную ма- 
шину Јауа с параметром -епарІеаѕѕегііопѕ из командной строки, и оставить их раз- 
решенными. 
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В реализации Јауа можно (и нужно) ввести в утверждение описательную 
строку следующим образом: 


аззегеЕ геѕоії != пи11 && гезо1е.517е() > 0 : "Еюріу гезо1е Егом ХУ"; 


Утверждения полезны также для проверки функционирования алгоритмов. 
Так, если написать алгоритм изощренной сортировки под названием пу ѕогЁ, 
проверить его работоспособность можно, например, таким образом: 

рооКкѕ = му зогї (Ғіпа ("$с1Е1")) 

аѕѕегі (іѕ ѕогіеа? (роокѕ)) 

Ни в коем случае не пользуйтесь утверждениями вместо реальной обработки 
ошибок. Утверждения позволяют проверить то, что никогда не должно случить- 
СЯ. Вряд ли вам захочется написать код, аналогичный приведенному ниже. 

рисѕ ("Епіег 'У' ог '№': ") 

апз = адеіѕ [0] # взять первый символ из ответа 

аѕѕегї ((сһ == 'Ү') || (ср == '№')) # Явно неудачная идея! 


То, что большинство реализаций оператора аѕѕегі просто завершают про- 
цесс, если утверждение не выполняется, не является причиной для того, чтобы 
это происходило и в написанных вами версиях программного обеспечения. Так, 
если вам требуется освободить используемые ресурсы, перехватите исключение, 
возникшее в утверждении, или прервите выход из программы, а затем выполни- 
те свой обработчик ошибок. Нужно лишь сделать так, чтобы код, выполняемый 
в течение этих истекающих миллисекунд, прежде всего не опирался на инфор- 
мацию, послужившую причиной того, что утверждение не подтвердилось. 


УТВЕРЖДЕНИЯ И ПОБОЧНЫЕ ЭФФЕКТЫ 


Если код, вводимый для обнаружения ошибок, фактически приводит к но- 
вым ошибкам, то положение только усугубляется. Такое может случиться и с 
утверждениями, если проверка условия имеет побочные эффекты. Например, 
написание следующего фрагмента кода вряд можно считать удачной идеей: 


мһі1е (ісег.ҺһаѕМогеЕ1іетепіѕ ()) { 
азѕегі (іїег.пехіЕ1етепі () != пи11); 
Ор]есЕ орј = ібег.пехїЕ1етепі (); 
// 


} 


Вызов .пехіЕ1етепі () в утверждении имеет побочный эффект, проявляю- 
щийся в том, что итератор пропускает извлекаемый элемент, и поэтому в цикле 
мһі1е будет обработана лишь половина элементов, находящихся в коллекции. 
В таком случае было бы лучше написать данный цикл следующим образом: 


мһіЈіе (ііег.һаѕМогеЕіетепіѕ ()) { 
Орјесё орј = 1{ег.пехЕЕ1етеп (); 
аззегі (орј != по]1); 


И холе 
} 
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Это разновидность неопределенной, едва уловимой программной ошибки 
под названием гейзенбаг", которая изменяет поведение отлаживаемой системы. 
Мы также считаем, что теперь, когда в большинстве языков имеется приличная 
поддержка функций, циклически перебирающих коллекции, такого рода явный 
цикл не нужен и является неудачной разновидностью их обработки. 


ОСТАВЛЯЙТЕ ВКЛЮЧЕННЫМ РЕЖИМ УТВЕРЖДЕНИЙ 
В отношении утверждений существует весьма распространенное заблуждение: 


Утверждения вносят некоторые издержки в код. Они проверяют то, 
что никогда не должно случиться, и поэтому приводятся в действие 
только программной ошибкой в коде. И как только код будет проверен 
и доставлен потребителю, они больше не потребуются, а следователь- 
но, режим утверждений можно отключить, чтобы код выполнялся быс- 
трее. Утверждения являются средством отладки исходного кода. 


В приведенном выше рассуждении есть два заведомо ложных допущения. Во- 
первых, в нем предполагается, что во время тестирования обнаруживаются все 
программные ошибки. В действительности в любой сложной программе вряд 
ли удастся проверить даже мельчайшую долю всех перестановок, сделанных в 
исходном коде. И во-вторых, оптимисты забывают, что их программы выпол- 
няются в опасной среде. Во время тестирования крысы вряд ли перегрызут ка- 
бель связи, игрок исчерпает оперативную память по ходу компьютерной игры, 
а журнальные файлы заполнят весь раздел запоминающего устройства. Подоб- 
ные события скорее могут произойти при выполнении программы в реальной 
эксплуатационной среде. Поэтому вашей первой линией обороны должна стать 
проверка любых возможных ошибок, а второй линией — применение утверж- 
дений, чтобы попытаться обнаружить пропущенные ошибки. 

Выключение режима утверждений при запуске программы в эксплуатацию 
можно сравнить с хождением по натянутой под куполом цирка проволоке без 
страховочной сетки только потому, что это уже однажды удалось сделать. В этом 
есть драматичность и зрелищность, но не страховка от смертельного исхода. 

Даже если вам приходится решать вопросы производительности, выключайте 
лишь те утверждения, которые действительно отрицательно влияют на произ- 
водительность. Так, приведенный выше пример сортировки может быть крайне 
важной частью приложения, которая должна выполняться побыстрее. Добав- 
ление в нее проверки означает еще один проход данных, что может оказаться 
неприемлемым. Поэтому сделайте эту конкретную проверку необязательной, но 
оставьте остальные проверки без изменений. 


* Название гейзенбаг (Неіѕепьџир) происходит от принципа неопределенности Г ейзенберга 
из квантовой механики и, собственно, программной ошибки (Бир). Подробнее об этом 
см. по адресу Һр: / /ммм.ерѕ.тсді11.са/јагадоп/јагадоп.һітм1 #һеіѕеприд или 
Һіірѕ://ги.мікіредіа.огад/мікі/ Гейзенбаг. 
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= я: о 
. ОСА приносит НЕМАЛУЮ ПРИБЫЛЬ | 3 


Бывший сосед Энди руководил небольшой начинающей компанией, произ- 
водившей сетевые устройства. Одним из секретов их успеха было решение 
оставить утверждения на месте в рабочих версиях. Эти утверждения были 
достаточно грамотно составлены, чтобы сообщать всю информацию, име- 
ющую отношение к сбоям, а также представлены конечному пользовате- 
лю через изящного вида интерфейс. Такой уровень организации откликов 
реальных пользователей в конкретных условиях эксплуатации позволял 
разработчикам затыкать дыры в защите и устранять едва заметные, труд- 
но воспроизводимые программные ошибки, а следовательно, производить 
необыкновенно устойчивое, надежное программное обеспечение. Эта не- 
большая, малоизвестная компания производила настолько добротную про- 
дукцию, что вскоре была приобретена за сотни миллионов долларов. Но это 
так, к слову. 


Другие разделы, связанные с данной темой 
• Тема 23. Проектирование по контракту. 
• Тема 24. Мертвые программы не лгут. 
• Тема 42. Тестирование на основе свойств, глава 7 “По ходу кодирования". 


• Тема 43. Будьте осторожны, глава 7 “По ходу кодирования". 


Упражнения 


16. Быстрая проверка на чувство реальности. Какие из перечисленных ниже 
“невозможных” событий могут все же произойти? 


- Месяц, в котором меньше 28 дней. 


| 


Код ошибки, возвращаемый из системного вызова и обозначающий не- 
возможность доступа к текущему каталогу. 


— В языке С++: а = 2, р = 3, но (а + БЫ) не равно 5. 


| 


Треугольник, сумма углов которого не равна 180°. 
- Минута, не насчитывающая 60 секунд. 


— (а + 1) <= а 


Е Е И НЫ лен + С В 
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КАК СБАЛАНСИРОВАТЬ РЕСУРСЫ 


“Зажечь свечу — отбросить тень...” 
Урсула К. Ле Гуин”, Волшебник Земноморья (А УЙгата оў Еагіћѕеа) 


Когда мы программируем, то так или иначе манипулируем ресурсами: опе- 
ративной памятью, транзакциями, потоками выполнения, сетевыми соединени- 
ями, файлами, таймерами, т.е. всеми средствами с ограниченной доступностью. 
И чаще всего ресурсы используются по вполне предсказуемому шаблону: снача- 
ла ресурс выделяется, затем используется и, наконец, освобождается. 

Тем не менее у многих разработчиков нет постоянного плана по выделению и 
освобождению ресурсов. Поэтому дадим в этой связи следующий совет: 


Завершайте то, что начали 


Этот совет легко применить в большинстве случаев. Он просто означает, что 
функция или объект, выделяющие ресурс, должны отвечать за его освобожде- 
ние. Рассмотрим его применение на конкретном примере неудачно написанно- 
го на КиБу фрагмента кода, открывающего файл, читающего из него сведения 
о клиенте, обновляющего отдельное поле данных и записывающего результат 
обратно в файл. Ради простоты и большей ясности данного примера из него 
исключена проверка ошибок, как показано ниже. 


ЧеЁ геаа соиѕіотег 
@сиѕсомег Е11е = Е11е.ореп (@пате + ".гес", "т+") 
@раіапсе = Відресіта1 (@соизіотег #і1е.дебзѕ) 

епа 


её игіёе сиѕіотег 
@сизсомег Ёі1е.геміпа 
@соѕёотег Ғі1е.роёѕ @ра1апсе.ёо ѕ 
@сиѕёіотег Ё11е.с1озе 

епа 


бе# прдасе соѕботег (Егапѕасёіоп атоопі) 
геаа сиѕіотег 
@ра]апсе = @а1апсе. ааа (ігапѕасііоп апоцпі, 2) 
мгііе сиѕіотег 
епа 
На первый взгляд, подпрограмма џрдаёе сизіотег () из приведенного 
выше фрагмента кода выглядит вполне обоснованно. По-видимому, для реали- 
зации ее логики потребуется прочитать запись, обновить баланс на текущем 
счете и записать обновленную запись обратно. Тем не менее за такой опрят- 


> Отѕша К. 1е Сша — современная американская писательница и литературный критик, 
автор романов и повестей в жанре фэнтези. — Примеч. пер. 
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ностью скрывается главная трудность. Подпрограммы геаа сиоѕіотег () 
и мгіе сиѕіотег () тесно связаны‘, поскольку совместно пользуют- 
ся общей переменной экземпляра сиѕёотег #і1е. Сначала подпрограмма 
мгіе сиѕёопег () открывает файл и сохраняет ссылку на него в переменной 
сиѕіотег Ёі1е, а затем подпрограмма геаа сиоѕіотег () использует сохра- 
ненную ссылку, чтобы по ее завершении закрыть файл. Но эта общая перемен- 
ная даже не упоминается в подпрограмме џрӣаёе сиѕіопег (). 

Почему это плохо? Рассмотрим пример незадачливого программиста, по- 
лучившего задание внести следующее изменение в спецификацию сопровож- 
даемого им приложения: баланс на счете должен обновляться лишь в том 
случае, если новое значение не является отрицательным. С этой целью он об- 
ращается к исходному коду и вносит следующие изменения в подпрограмму 
ирдӢаёе сиѕїіотег (): 


её џордӢаёе соиѕіотег (ігапѕасііоп апоицпі) 
геаа сизбомег 
1Е (©гапѕасбіоп амоппе >= 0.00) 
@ра]апсе = @ра1апсе.ааа (їгапѕасёіоп атмоопё, 2) 
мгісе соиѕёотег 
епа 
епа 


Во время тестирования этот код вроде бы ведет себя как следует. Но когда этот 
код запускается в эксплуатацию, он терпит крах несколько часов спустя, завер- 
шаясь предупреждением о том, что открыто слишком много файлов. И оказыва- 
ется, что при определенных обстоятельствах подпрограмма мгііе сиѕіотег () 
не вызывается. И когда этого происходит, файл не закрывается. 

Весьма неудачным решением данной задачи была бы попытка реализовать 
особый случай в подпрограмме џрдӢаёе сиѕіотег (): 


ЧеЁ џрдӢаёе соѕіотег (ёгапѕасііоп атоцпі) 
геаа сиѕіоптег 
1 (ёгапѕасёіоп атоџпі >= 0.00) 
@ра1апсе += Відресіта1 (їгапѕасёіоп амомпе, 2) 
мгіе сиѕіотег 
е1зе 
@сизкомекг Ғі1е.с1оѕе # Плохое решение! 
епа 
епа 


И хотя такое решение устраняет затруднение, поскольку файл теперь будет 
закрыт независимо от нового баланса на счете, тем не менее, теперь данное 
исправление означает, что все три подпрограммы связаны общей переменной 
сизіотег Ёі1е, а слежение за тем, открыт ли файл или закрыт, начинает при- 


6 Подробнее об опасностях, кроющихся в связанном коде, см. в разделе “Тема 28. Развязка” 
главы 5. 
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ходить в полный беспорядок. В итоге наш программист попадает в ловушку, и 
все дело начнет быстро катиться под откос, если продолжить его в том же духе. 
Это и есть признак несбалансированности! 

Совет “Завершайте то, что начали” предписывает, что в идеальном случае 
подпрограмма, выделяющая ресурс, должна его освободить. Чтобы восполь- 
зоваться этим советом, реорганизуем немного рассматриваемый здесь код, как 
показано ниже. 


ЧеЁ геаа сизфопег (Ғі1е) 
@ра1апсе=Відресіта1 (ЁіІе.деізѕ) 

епа 

её игііе сиѕіотег (Ё11е) 
Е1]е.гем1па 
Ғі1е.роибѕ @бра1апсе.ёо з 


епа 

де џрдӢаіе сиѕіотег (ёгапѕасёіоп атоипі) 
Е1]е=Р11е.ореп (@паме + ".гес", "г+") # >-- 
геаа сиѕёоптег (Ғі1е) Ў | 
@раіапсе = @ра1апсе.ааа (ёгапѕасііоп атоипё, 2) ы | 
Е1]1е.с1о5е # <-- 

епа 


Вместо того чтобы сохранять ссылку на файл, мы изменили в данном случае 
исходный код таким образом, чтобы передавать ее в качестве параметра’. И те- 
перь вся ответственность за манипулирование файлом возлагается на подпро- 
грамму џрдӢаќе соѕёотег (), которая открывает файл и (по завершении того, 
с чего она начинается) закрывает его перед самым возвратом. Таким образом, в 
данной подпрограмме балансируется пользование файлом как внешним ресур- 
сом, поскольку операции его открытия и закрытия происходят в одном и том же 
месте, и вполне очевидно, что на каждую операцию открытия файла приходится 
соответствующая операция его закрытия. Кроме того, благодаря реорганизации 
кода выводится из употребления скверная общая переменная. 

В рассматриваемый здесь код можно внести еще одно важное усовершенство- 
вание. Во многих современных языках срок действия ресурса можно заключить 
в пределы некоторого замкнутого блока. Так, в языке КиБу имеется разновид- 
ность оператора ореп, передающего ссылку на открытый файл такому блоку, 
как показано ниже в промежутке между операторами до и епа. 


её орЧафе сиѕіотег (Еёгапѕасііоп атоцопі) 


Еі1Іе.ореп (@паме + ".гес", "г+") ао |Ғі1е | # >-- 
геаа соѕіотег (ЁЕ11е) ы | 
@ра1апсе = @ра1апсе.ааа (&гапзас®1оп_ атоопі, 2) # | 
місе сиѕіотег (Ғі1е) # | 

епа т< 


епа 


7 См. совет 50 в главе 5. 
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В данном случае переменная Ғі1е выходит в конце блока из области своего 
действия, и на этом внешний файл закрывается. А программист избавляется от 
необходимости помнить, что следует непременно закрыть файл и тем самым 
освободить ресурс, поскольку это гарантированно будет сделано автоматически. 
Если же гложут сомнения, то всегда стоит сократить область действия. 


Действуйте локально 


ВЛОЖЕННОЕ ВЫДЕЛЕНИЕ РЕСУРСОВ 


Основной шаблон выделения ресурсов может быть расширен для тех подпро- 
грамм, которым одновременно требуется не один ресурс. И для этого имеются 
лишь следующие два предложения. 


• Освободить ресурсы в порядке, противоположном тому, в каком они были 
выделены. Подобным образом ресурсы не останутся зависшими, если один 
из них содержит ссылки на другие. 


® Если один и тот же ряд ресурсов выделяется в разных местах исходного 
кода, они должны выделяться в том же самом порядке. Благодаря этому 
снижается вероятность взаимной блокировки. Так, если процесс А затре- 
бует ресурс 1 и готов востребовать ресурс 2, тогда как процесс В уже за- 
требовал ресурс 2 и пытается заполучить ресурс 1, то оба процесса перей- 
дут в состояние бесконечного ожидания. 


Независимо от того, какого рода ресурсы используются, будь то транзакции, 
сетевые соединения, оперативная память, файлы, потоки выполнения или окна, 
применяется следующий основной шаблон: тот, кто выделяет ресурс, должен 
отвечать за его освобождение. Тем не менее этот принцип может быть развит 
далее в некоторых языках. 


ОБЪЕКТЫ И ИСКЛЮЧЕНИЯ 


Баланс между выделением и освобождением ресурсов напоминает конс- 
труктор и деструктор класса в объектно-ориентированном программировании. 
В частности, класс представляет собой ресурс, конструктор представляет собой 
выделение конкретного объекта данного ресурса, а деструктор удаляет его из 
области видимости. 

Если вы программируете на объектно-ориентированном языке, то можете 
найти удобной инкапсуляцию ресурсов в классах. Всякий раз, когда вам пот- 
ребуется ресурс конкретного типа, вы получаете экземпляр объекта данного 
класса. А когда объект выходит из области своего действия или утилизируется 
сборщиком “мусора’, деструктор этого объекта освобождает заключенный в нем 
ресурс. Такой подход дает особые преимущества при программировании на тех 
языках, где исключения могут мешать освобождению ресурсов. 
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БАЛАНС ВО ВРЕМЕНИ 


В данной теме рассматриваются в основном эфемерные ресурсы, использу- 
емые для выполнения определенного процесса. Но вам, возможно, придет- 
ся рассмотреть и другие сложные вопросы, которые могли быть оставлены 
без внимания. 


Как, например, обрабатывать журнальные файлы? Так, если вы, формируя 
данные, исчерпаете все свободное место на запоминающем устройстве, то 
следует ли вместо этого организовать ротацию и очистку журнальных фай- 
лов? А как насчет удаления неофициальных файлов отладки? Если вы вво- 
дите протокольные записи в базу данных, то есть ли аналогичный процесс, 
определяющий окончание срока их действия? Рассмотрите возможность 
сбалансировать все, что ни создается и требует конечного ресурса. 


И, наконец, не осталось ли еще что-нибудь вне вашего внимания? 


БАЛАНС ИСКЛЮЧЕНИЙ 


В языках, поддерживающих исключения, освобождение ресурсов может быть 
затруднено. Так, если генерируется исключение, то как гарантировать очистку 
всего, что было выделено до этого исключения? Ответ на этот вопрос зависит 
от поддержки этой возможности языком. Как правило, для этого имеются две 
возможности. 


1. Воспользоваться областью видимости переменной (например, стековыми 
переменными в С++ или Ки). 


2. Воспользоваться оператором #іпа11у в блоке операторов ёгу/саїсћ. 


По обычным правилам соблюдения области видимости в таких языках, как 
С++ или Киѕі, память, выделяемая для переменной, будет утилизирована, как 
только переменная выйдет из области своей видимости посредством возврата из 
функции, завершения блока кода или исключения. Но для очистки любых вне- 
шних ресурсов можно также осуществить привязку к деструктору переменной. 
В приведенном ниже примере кода на языке Киѕї файл автоматически закроется, 
как только переменная ассоипіёѕ выйдет из области своей видимости. 


{ 


Іеє тоё ассоцпізѕ = Е11е: : ореп ("тудаёа.бхі") ?; // >-- 
// Пользуемся переменной 'ассоцпе$' А | 
Р // | 
} й) «= 


// Теперь переменная !'ассоцџпёѕ' находится вне области 
// своей видимости, а файл автоматически закрывается 
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Другая возможность, если только она поддерживается в конкретном языке, 
состоит в применении оператора Ғіпа11у, как показано ниже. Этот оператор 
гарантирует, что указанный код будет выполнен независимо от того, будет ли 
сгенерировано исключение в блоке операторов ёгу/саёсћ. 

+гу 

// нечто не внушающее доверия 
саёсћ 
// сгенерировано исключение 


Ғіпа11у 
// очистить в любом случае 


Но здесь есть одна хитрость. 


Антишаблон исключений 


Нам часто приходилось наблюдать, как программисты пишут следующий 
КОД: 
ред1п 
{21109 = а11осаіе гезоигсе () 
ргосез$ (6119) 
Ғіпа11у 


дӢеа11осаѓе (ёһіпа) 
епа 


Можете ли вы обнаружить ошибку в этом коде? Что, если выделить ресурс не 
удастся и возникнет исключение? Оно будет перехвачено в операторе Ғіпа11у, 
который попытается освободить ресурс #һіпа, который не был выделен. 

Правильный шаблон для освобождения ресурсов в среде с исключениями 
выглядит следующим образом: 


їһіпа = а11осафе гезопгсе () 
редіп 
ргосе$$ (іћіпа) 
Ғіпа11у 
дӢеа11осаѓе (+їһіпд) 
епа 


Когда НЕЛЬЗЯ СБАЛАНСИРОВАТЬ РЕСУРСЫ 


Иногда основной шаблон для выделения ресурсов оказывается просто не- 
пригодным. И обычно это бывает в тех программах, в которых применяются 
динамические структуры данных. Так, одна подпрограмма может выделить об- 
ласть памяти и связать ее с какой-нибудь более крупной структурой, где она 
может оставаться некоторое время. 

Выход из этого положения состоит в том, чтобы установить семантический 
инвариант для выделения памяти. При этом необходимо решить, кто должен 
отвечать за данные в агрегированной структуре данных. Что произойдет, если 
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освободить структуру верхнего уровня? Для этого имеются три основные воз- 
можности. 


е Структура верхнего уровня отвечает за освобождение любых подструктур, 
которые она содержит. Из этих структур затем удаляются находящиеся в 
них данные и Т.д. 


® Структура верхнего уровня просто освобождается. А любые структуры, 
на которые она указывает и которые нигде больше не делаются ссылки, 
“зависают” 


® Структура верхнего уровня отказывается освобождаться, если она содер- 
жит любые подструктуры. 


Выбор конкретной возможности зависит от обстоятельств каждой структуры 
данных в отдельности. Тем не менее ее необходимо выразить явно для каждой 
структуры данных и согласованно реализовать свое решение. Реализация любой 
из этих возможностей в таких процедурных языках, как С, может оказаться за- 
труднительной, поскольку сами структуры данных неактивны. В таких случаях 
мы предпочитаем написать для каждой из основных структур данных модуль, 
обеспечивающий стандартное выделение и освобождение ресурсов, требующих- 
ся данной структуре. (Такой модуль может также предоставить такие ресурсы, 
как вывод на печать при отладке, сериализация и десериализация, а также пе- 
рехватчики обхода.) 


ПРОВЕРКА БАЛАНСА 


Программисты-прагматики никому не доверяют, в том числе и самим себе, и 
поэтому мы считаем, что всегда стоит писать такой код, в котором проверяет- 
ся, действительно ли ресурсы освобождены должным образом. В большинстве 
приложений это, как правило, означает создание оболочек для каждого типа 
ресурса, а также их применение для отслеживания всех операций выделения и 
освобождения ресурсов. В некоторых местах кода логика программы будет дик- 
товать нахождение ресурсов в определенном состоянии, поэтому для его про- 
верки следует воспользоваться оболочками. Например, в верхней части главно- 
го цикла обработки данных в долго выполняемой программе, обслуживающей 
запросы, вероятно, имеется единственная точка, где ожидается поступление 
очередного запроса. Это удобное место, где можно гарантировать, что исполь- 
зование ресурса не возросло с момента последнего выполнения данного цикла. 
На более низком, хотя и менее полезном уровне можно вложить средства в инс- 
трументальные средства, которые, среди прочего, проверяют выполняющиеся 
программы на наличие утечки памяти. 
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Другие разделы, связанные с данной темой 
® Тема 24. Мертвые программы не лгут. 


® Тема 30. Преобразовательное программирование, глава 5 “Гибкость или 
ломкость’. 


е Тема 33. Разрывание временного связывания, глава 6 “Параллельность”. 


Задачи 


• В отсутствие способов, всегда гарантирующих освобождение ресурсов, 
может помочь последовательное применение некоторых методик. Ранее 
в этом разделе пояснялось, каким образом установка семантического ин- 
варианта для основных структур данных может привести к правильным 
решениям по поводу освобождения оперативной памяти. Выясните, как 
это делается. Для этого вам, возможно, придется вернуться к материалу 
раздела “Тема 23. Проектирование по контракту”. 


Упражнения 


17. Некоторые программирующие на Си С++, как правило, устанавливают зна- 
чение указателя равным МОГТ, после освобождения области памяти, на ко- 
торую он ссылается. Чем хороша эта идея? 


18. Некоторые программирующие на Јауа устанавливают значение МОТТ для 
объектной переменной по окончании использования объекта. Чем хороша 
эта идея? 


Ме ас АТМА Аар А ЕЛА Ч ЧАЗА Ата де еее валу ДА С ии Ла ЗДАН уче Оита риса икота Ипа ола нА ААА АФУ Атр, омичи МАЈ а а ТРУНА ХЕ дикое Алеев лате 1, 


НЕ ОПЕРЕЖАЙТЕ СВЕТ ФАР 
ВАШЕГО АВТОМОБИЛЯ 


“Трудно делать предсказания, особенно о будущем”. 
Лоуренс “Йоги” Берра?, из датской поговорки 


Представьте темную дождливую ночь. Двухместный автомобиль резко по- 
ворачивает на крутых поворотах узкой извилистой горной дороги, едва впи- 
сываясь в них. И вдруг под колесо автомобиля попадает шпилька для волос, 
в результате чего он ударяется в слабое дорожное ограждение, стремительно 
падает вниз и разбивается вдребезги о землю в лежащей ниже долине. Сотруд- 
ники местной полиции прибывают на место происшествия, осматривают его, и 
старший офицер, печально кивая головой, говорит: “Видно, опередили свет фар 
своего автомобиля”. 


3 Тамтепсе “Үорі” Вегга — известный американский бейсболист. — Примеч. пер. 
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Неужели двухместный автомобиль мог ехать быстрее скорости света? Нет, 
конечно, поскольку превысить этот предел скорости не позволяют законы фи- 
зики. Офицер имел в виду способность водителя вести машину и вовремя оста- 
новиться, реагируя на дорожную обстановку, освещаемую светом фар. 

Свет фар распространяется в ограниченных пределах, называемых проекии- 
онным расстоянием, а дальше свет фаз становится слишком рассеянным, чтобы 
эффективно освещать дорогу. Кроме того, фары проецируют свет по прямой 
осевой линии, ничего не освещая за ее пределами, в том числе повороты, подъ- 
емы и впадины на дороге. Согласно данным Национального управления безо- 
пасностью движения на трассах (МаНопа] Нірћмау ТгаЁбс За ебу Айатіпіѕігайоп — 
МНТЅА) среднее расстояние, освещаемое фарами ближнего света, составляет 
около 50 м. Но, к сожалению, безопасный тормозной путь на скорости 65 км/час 
составляет 57 м, тогда как на скорости 110 км/час — уже около 140м.? Следова- 
тельно, опередить свет фар своего автомобиля очень легко. 

В разработке программного обеспечения дальность света наших “передних 
фар” столь же ограничена. Мы не можем заглянуть слишком далеко в будущее, и 
чем дальше мы отклоняем свой взгляд от основной оси, тем темнее становится. 
Поэтому программист-прагматик должен придерживаться следующего твердого 
правила: 


Всегда предпринимайте небольшие шаги 


Старайтесь всегда предпринимать небольшие, обдуманные шаги, проверяя 
ответную реакцию и корректируя свои действия, прежде чем продолжить даль- 
ше. И ни в коем случае не предпринимайте слишком большой шаг и не беритесь 
за слишком крупную задачу. 

А что имеется конкретно в виду под ответной реакцией? Все, что независимо 
подтверждает или опровергает ваше действие. Например: 


<< > 
ә результаты в цикле ‘чтение-вычисление-вывод” (КЕРІ) обеспечивают от- 
ветную реакцию на ваше понимание АРІ и алгоритмов; 


• модульные тесты обеспечивают ответную реакцию на последнее измене- 
ние кода; 


® демонстрация пользователям и ее обсуждение обеспечивают ответную ре- 
акцию на функциональные средства, удобство и простоту использования. 


А какую задачу следует считать слишком крупной? Любую задачу, которая 
требует “предсказания будущего”. Подобно ограниченной дальности света пере- 


7 В соответствии со следующей формулой МНТЅА: безопасный тормозной путь = рас- 
стояние, проходимое автомобилем за время реакции водителя + путь торможения, при 
условии что среднее время реакции составляет 1,5 с, а ускорение — 5,19 м/с”. 
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дних фар автомобиля, мы можем также заглянуть в будущее, возможно, на один 
или два шага, а, может быть, самое большее — на несколько часов или дней. 
Выйдя за эти пределы, можно очень быстро перейти от обоснованного предполо- 
жения к досужим домыслам. Легко впасть в грех предсказания будущего, когда 
приходится: 


® оценивать даты завершения работ на месяцы вперед; 
• планировать расширяемость сопровождения в перспективе; 
® предугадывать будущие потребности пользователей; 


• прогнозировать техническую пригодность в будущем. 


Но мы уже слышим ваши громкие возражения: “Разве мы не проектируем с 
учетом будущего сопровождения?” Да, конечно, но лишь до определенного мо- 
мента, т.е. настолько, насколько мы в состоянии смотреть вперед. Чем больше 
вам приходится предсказывать будущее, тем больше риск, что вы ошибетесь. 
И вместо того чтобы тратить усилия на проектирование для неопределенного 
будущего, можно всегда прибегнуть к разработке заменяемого кода. Старайтесь 
облегчить отказ от непригодного кода и его замену более пригодным кодом. 
Возможность заменить код помогает также его сцеплению, связыванию и соб- 
людению принципа ОКУ, что приводит к более качественному проектированию. 
И хотя вы можете быть уверены в будущем, всегда существует вероятность, что 
не за горами окажется нечто совсем негаданное, словно черный лебедь. 


ЧЕРНЫЕ ЛЕБЕДИ 


В своей книге Тйе Віаск $мап: Тһе Ітрасі оў ће Нір!у ГтртобаЫЕ [Та110] Нассим 
Наколас Талеб утверждает, что все значительные события в истории произошли 
от широко известных, трудно предсказуемых и редких событий, выходящих за 
пределы обычных ожиданий. Эти невероятные события имеют несоразмерный 
эффект, несмотря на свою статистическую редкость. Кроме того, наши когни- 
тивные отклонения приводят к тому, что мы не замечаем, как перемены неза- 
метно проникают в нашу работу, доходя до краев (см. раздел “Тема 4. Суп из 
камней и вареные лягушки” главы 1 “Философия прагматизма”). 

Ко времени выхода в свет первого издания этой книги в компьютерных жур- 
налах и оперативно доступных форумах разгорелась полемика по следующему 
вопросу: “Кто одержит верх в войнах настольных СОТ между стилями Моќіѓ и 
ОрепГ.ооК?”! Этот вопрос был поставлен неверно. Вполне вероятно, что вы во- 
обще не слышали об этих технологиях, поскольку ни одна из них не одержала 
верх, и в данной области быстро возобладала веб-технология, ориентированная 
на браузеры. 


10 Мобі# и ОрепГооК были стандартными графическими интерфейсами для системы 
Х-УЙпдом на рабочих станциях (Опіх. 
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Избегайте предсказания будущего 


Завтра зачастую выглядит очень похожим на сегодня. Но на это не следует 
особенно полагаться. 


Другие разделы, связанные с данной темой 


ө Тема 12. Трассирующие пули, глава 2 “Прагматичный подход”. 


Тема 13. Прототипы и памятные записки, глава 2 “Прагматичный подход”, 


ә 


Тема 40. Рефакторинг, глава 7 “По ходу кодирования”, 


Тема 41. Тестировать, чтобы кодировать, глава 7 “По ходу кодирования”, 


Тема 48. Сущность гибкости, глава 8 “До начала проекта”. 


Тема 50. Кокосами не обойтись, глава 9 “Прагматичные проекты”. 


ГЛАВА 5 


_ ТИБКОСТЬ ИЛИ ЛОМКОСТЬ 


Жизнь не стоит на месте, как, впрочем, и код, который мы пишем. Чтобы 
поспевать за бешеным темпом нынешних перемен, нам приходится каждый раз 
прилагать усилия для написания кода, который должен быть как можно более 
слабо связанным, т.е. гибким. В противном случае наш код может быстро ус- 
тареть или оказаться слишком хрупким для исправления и в конечном счете 
может быть оставлен без внимания в безумном стремлении в будущее. 

В разделе “Тема 11. Обратимость” главы 2 “Прагматичный подход” упоми- 
налось о рисках необратимых решений. В этой главе речь пойдет о том, как 
принимать обратимые решения, чтобы сохранить свой код гибким и приспо- 
сабливаемым к неопределенному окружающему миру. 

Сначала в этой главе будет рассмотрено связывание, т.е. создание зависимос- 
тей между фрагментами кода, а затем развязывание, позволяющий сохранить 
отдельные части кода разделенными, тем самым убавив связывание. 

Далее в этой главе будут рассмотрены методики, которые можно применять 
при манипулировании реальным миром. В соответствующем разделе будут ис- 
следованы различные стратегии, помогающие управлять событиями и реагиро- 
вать на них, что является очень важной особенностью современной разработки 
приложений. 

Традиционный процедурный и объектно-ориентированный код может быть 
тесно связан в определенных целях. Поэтому в разделе “Преобразовательное 
программирование” поясняется, как воспользоваться с выгодой более гибким и 
ясным стилем программирования, предлагаемым конвейерами функций, даже 
если они не поддерживаются непосредственно в конкретном языке. 

Обычный стиль объектно-ориентированного программирования может за- 
вести в еще одну ловушку. Не попадайтесь в нее, иначе вам придется заплатить 
непомерный налог на наследование. В соответствующем разделе будут рассмот- 
рены более подходящие альтернативы, позволяющие сохранить гибкость кода и 
упростить его изменение. 

И, разумеется, чтобы сохранить гибкость кода, лучше писать его меньше. 
Изменение кода оставляет возможность вносить новые программные ошиб- 
ки. В разделе “Конфигурирование” поясняется, как вынести все подробности 
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из кода туда, где их можно более безопасно и легко изменить. Все рассматри- 
ваемые в этой главе методики помогают писать код, который сгибается, но не 
ломается. 


РАЗВЯЗЫВАНИЕ 


“Когда мы пытаемся выбрать что-нибудь само по себе, 
то обнаруживаем, что оно зацепляется 
за все остальное в мире”. 


Джон Мьюр', Мое первое лето в Сьерре 
(Му Еігѕі $иттет т ће Ѕіетта) 


В разделе “Тема 8. Сущность качественного проектирования” главы 2 “Праг- 
матичный подход” утверждалось, что, применяя подходящие принципы проек- 
тирования, можно упростить внесение изменений в исходный код. Связывание 
враждебно изменению, поскольку связывает вместе компоненты, которые долж- 
ны изменяться параллельно. И это затрудняет внесение изменений, поскольку 
приходится тратить время на отслеживание всех частей, которые должны быть 
изменены, или же на выяснение причин, по которым все сломалось, когда из- 
менился всего лишь один компонент, а не другие компоненты, с которыми он 
был связан. 

Когда вы разрабатываете что-нибудь такое, что должно быть таким же про- 
чным, как мост или башня, тогда вам, возможно, придется связать вместе два 
компонента, как показано ниже. 


Совместно связи делают структуру прочной. Сравните ее с чем-то наподобие 
приведенной ниже структуры, где структурная прочность напрочь отсутствует, 
поскольку одни связи могут измениться, а другие просто приспособиться к это- 
му изменению. 


А Јоћп Миг — американский естествоиспытатель, писатель ХІХ века, и защитник дикой 
природы, один из инициаторов создания в США национальных парков и заповедных тер- 
риторий. — Примеч. пер. 
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При проектировании мостов требуется сохранить их форму, помимо того, что 
их конструкции должны быть жесткими и прочными. При проектировании про- 
граммного обеспечения, которое предполагает внесение изменений, требуется со- 
вершенно противоположное: оно должно быть гибким. А для этого одни компо- 
ненты должны быть связаны с как можно меньшим числом других компонентов. 

И хуже того, связывание транзитивно. Так, если компонент А связан с ком- 
понентами В и С, компонент В — с компонентами М и М, компонент С — ком- 
понентами Х и У, то компонент А оказывается связанным с компонентами В, 
С, М, М, Хиу. Это означает, что необходимо следовать приведенному ниже 
простому принципу. 


Развязанный код проще изменить 


Если принять во внимание, что для конструирования кода, как правило, 
не применяются стальные балки и заклепки, то что же означает развязывание 
кода? В этом разделе будут рассмотрены следующие вопросы. 


• Крушения поездов — цепочки вызовов методов. 
® Глобализация — опасности статических элементов. 


е Наследование — причины опасностей, таящихся в создании подклассов. 


В какой-то степени перечень этих вопросов искусственный. В частности, свя- 
зывание может происходить практически в любой момент, когда два фрагмента 
кода совместно используют нечто общее. Поэтому, читая приведенный ниже ма- 
териал, не упускайте из виду те базовые шаблоны, которые вы можете применять 
в своем коде. А кроме того, постоянно ищите следующие признаки связывания. 


ә Причудливые зависимости между несвязанными модулями или библио- 
теками. 


ә “Простые” изменения в одном модуле, распространяющиеся через несвя- 
занные модули или вызывающие нарушения где-нибудь в системе. 


® Разработчики, боящиеся вносить изменения в код, поскольку они не зна- 
ют, на что это может повлиять. 


Ф Совещания, которые должны посещать все участники проекта, поскольку 
никто не знает, на кого окажут влияние планируемые изменения. 
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КРУШЕНИЯ ПОЕЗДОВ 


Всем нам не раз приходилось видеть, а возможно, и писать код, аналогичный 
приведенному ниже. 


рчЬ1Ііс уоіа арр1урізсоцпі (сазбомег, ог4ег іа, аізѕсоцпё) { 
ёоа1їіѕ = сиѕіотег 


.огаег$ 

„Ріпа (огаег 19а) 

.десТоёа1зѕ (); 
оёа15.адгапатТоёа1ї = ёоёса1ѕ.адгапатТоёаї - аіѕсоопі; 
оёа1ї1ѕ.аіѕсоцпі = аіѕсоипі; 


} 


В этом коде сначала получается ссылка на некоторые заказы из объекта за- 
казчика, затем используется этот заказ, а далее подводится ряд итогов по дан- 
ному заказу. Наконец, используя эти итоги, из общего итога вычитается скидка, 
после чего они обновляются с учетом данной скидки. 

В рассматриваемом здесь фрагменте кода производится обход пяти переход- 
ных уровней абстракции: от заказчика до итоговых сумм. В конечном счете в 
коде верхнего уровня должно быть известно, что объект заказчика раскрывает 
заказы, в заказах имеется метод Ғіпа (), принимающий идентификатор заказа 
и возвращающий заказ, а у объекта заказа имеется объект Соёа15ѕ с методами 
получения и установки общих итогов и скидок. И все это во многом становится 
известным неявно. Но еще хуже, что многое не сможет измениться в будущем, 
если данный код должен продолжать свою работу и дальше. Таким образом, все 
методы и свойства оказываются связанными вместе, подобно тому, как в поезде, 
терпящем крушение, сцеплены все вагоны. 

Допустим, в компании принимается следующее решение: скидка ни на один 
из заказов не должна превышать 40%. Спрашивается: где разместить код, соблю- 
дающий это правило? Можно предположить, что он относится к телу упомяну- 
той выше функции арр1урізсоцп+ (). Но это, конечно, лишь часть ответа на 
поставленный вопрос, и, учитывая то состояние, в каком теперь находится при- 
кладной код, нельзя с уверенностью сказать, что такой ответ окажется полным. 
Ведь в любом фрагменте кода, т.е. где угодно, можно установить поля в объекте 
Еофа1$, и если не уведомить заранее (памятной запиской) сопровождающего 
данный код, то он не проверит, соблюдается ли в этом коде новое правило. 

На данный вопрос можно, например, взглянуть с точки зрения обязанностей. 
Очевидно, что объект соіа1з должен отвечать за подведение итогов. Но он 
пока еще этого не делает и на самом деле служит лишь контейнером для целого 
ряда полей, которые доступны любому для запроса и обновления. Чтобы испра- 
вить этот недостаток, можно воспользоваться следующим принципом: 
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Указывай, а не спрашивай 


Этот принцип гласит: решения нельзя принимать на основании внутреннего 
состояния объекта, а затем обновлять данный объект. Ведь это полностью ни- 
велирует преимущества инкапсуляции и распространяет знание о реализации 
по всему коду. Поэтому первой мерой, предотвращающей крушение поезда, яв- 
ляется передача скидки объекту итогов, как показано ниже. 


рочЬ1іс уоіа арр1урізсочопі (соѕіотег, огаег іа, аізѕсоцпі) { 
сиѕіопег 
.огаег$ 
.Ғіпа (огаег 19) 
.аееТофа1$ () 
.арр1у01$сочцп® (аїіѕсоцпі); 


} 


Затруднение, подобное несоблюдению принципа “указывай, а не спрашивай” 
({е]]-4оп\{-а$К, ТОРА), возникает в связи с объектом заказчика и его заказами. 
В частности, нельзя извлекать список заказов и искать их. Вместо этого следует 
получить нужный заказ непосредственно от заказчика, как показано ниже. 


рир11с уоіа арріурГіѕзсоцпі (сазбомег, огдег іа, аіѕсоцпё) { 
сиѕіопег 
.Ғіпаогаег (огаег іа) 
.аеїТоіа1ѕ () 
.арр1іуріѕсоцпі (аі ѕсоцпі); 


} 


Это же относится и к объекту заказа и его итогов. Зачем внешнему миру 
знать, что в реализации заказа используется отдельный объект для хранения 
его итогов? 


рир1іс уоіа арріуріѕсоиопі (сизбомег, огаег іа, діѕсоцпё) { 
сцѕіотег 
.ҒіпаоОгаег (огаег 19) 
.арр1уріѕсоипі (аіѕсочопі); 


} 


И на этом можно бы остановиться. В данный момент можно было бы подумать, 
что принцип ТРА позволяет ввести метод арр1уріѕсоопіТоОгаег (огдег іа) 
в объекты заказчиков. И это в самом деле возможно, если слепо следовать дан- 
ному принципу. 

Но принцип ТОА нельзя считать законом природы. Это всего лишь шаблон, 
помогающий распознать затруднения. В данном случае удобно выявить тот 
факт, что у заказчика имеются заказы и один из них можно найти, запросив его 
у объекта заказчика. И это прагматичное решение. 
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Во всяком приложении имеются определенные понятия верхнего уровня, 
которые являются универсальными. В рассматриваемом здесь приложении эти 
понятия включают в себя заказчиков и заказы. Нет никакого смысла полностью 
скрывать заказы в объектах заказчиков, поскольку они существуют самостоя- 
тельно. Таким образом, можно без особых трудностей создавать АРІ, через ко- 
торые становятся доступными объекты заказов. 


Закон Деметры 


Разработчики нередко упоминают в своих беседах о связывании так называ- 
емый закон Деметры, который устанавливает руководящие принципы”, сформу- 
лированные в конце 1980-х годов Ианом Холландом. Он сформулировал их для 
того, чтобы помочь разработчикам проекта “Деметра” уточнить свои функции и 
развязать их. 

Закон Деметры гласит, что в методе, определенном в классе С, можно обра- 
щаться лишь к следующему: 


е другим методам экземпляра из класса © 
• его параметрам; 


® методам из объектов, которые в нем создаются и находятся как в стеке, так 
и в динамической области памяти (так называемой “куче”); 


ә глобальным переменным. 


В первом издании данной книги мы уделили немного времени описанию за- 
кона Деметры. Но за прошедшие с тех пор двадцать лет цвет этой благоухаю- 
щей розы несколько увял. Нам теперь не по душе само понятие “глобальная 
переменная” по причинам, поясняемым в следующем разделе. Кроме того, мы 
обнаружили, что пользоваться этим законом на практике нелегко. Это все рав- 
но, что синтаксически анализировать корректный документ всякий раз, когда 
вызывается метод. 

Тем не менее положенный в его основу принцип все еще остается правиль- 
ным. Мы лишь рекомендуем более простой способ выражения почти того же 
самого. 


Не связывайте вызовы методов в цепочку 


Старайтесь связывать не более двух вызовов методов через точку, получая 
доступ к какому-нибудь объекту. Такой доступ охватывает также те случаи, 
когда используются промежуточные переменные, как в следующем фрагменте 
кода: 


2 На самом деле это не закон, а, скорее, счастливая мысль Деметры. 
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# Это весьма скверный стиль 
атойпе = сиѕіотег.огаегѕ.1аѕі () .іоіа1зѕ () .атоцпі; 


# Как, впрочем, и этот: 
огаегѕ = сиѕіотег.огаӢегѕ; 
1аѕі = огӣегѕ.1аѕі (); 
фоЕа1$ = 1Іаѕі.іоіа1ѕ () ; 
атпоопі = ёоёа1ѕ.атоипі; 


Из данного правила имеется следующее существенное исключение: это пра- 
вило не применяется, если маловероятно, что все связываемое в цепочку вооб- 
ще изменится. На практике же в приложении может вполне измениться все, что 
угодно. Так, все, что находится в сторонней библиотеке, следует считать непос- 
тоянным, особенно если сопровождающие данной библиотеки знают об измене- 
ниях, вносимых в АРІ между ее последовательными выпусками. Но библиотеки, 
входящие в состав языков, вероятнее всего, окажутся довольно устойчивыми, а 
следовательно, нас вполне удовлетворит код, аналогичный приведенному ниже. 

реоріе 

.ѕзогі ру {|регзоп| регзоп.аде } 


.Ғігѕї (10) 
‚пар {| регзоп | регзоп.паме } 


Этот код был вполне работоспособным двадцать лет назад, когда мы напи- 
сали его на языке КиђБу в качестве примера для первого издания данной книги. 
И он, вероятнее всего, таковым и останется, если теперь обнаружить его в на- 
работках старых программистов. 


Цепочки и конвейеры 


В разделе “Преобразовательное программирование” далее в этой главе речь 
пойдет о составлении конвейеров из отдельных функций. В таких конвейерах 
данные преобразуются и передаются от одной функции к другой. Хотя это и не 
то же самое, что и крушение поезда из вызовов методов, поскольку в данном 
случае не делается опора на скрытые подробности реализации. 

Нельзя сказать, что конвейеры не вносят никакого связывания. Формат 
данных, возвращаемых одной функцией в конвейере, должен быть совместим 
с форматом данных, принимаемых следующей функцией. Как показывает наш 
опыт, такая форма связывания ставит намного меньше препятствий изменению 
кода, чем форма, внедряемая через крушения поездов. 


Изъяны глоБАЛИЗАЦИИ 


Глобально доступные данные служат коварным источником связывания ком- 
понентов приложения. Каждый фрагмент глобальных данных действует так, как 
будто каждый метод в приложении неожиданно получает дополнительный па- 
раметр. Ведь эти глобальные данные доступны буквально в каждом методе. 
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Глобальные данные связывают код по многим причинам. И самая очевидная 
из них состоит в том, что изменение реализации глобальных данных потенци- 
ально воздействует на весь код в системе. На практике, однако, такое воздейс- 
твие, безусловно, весьма ограничено. Затруднение на самом деле сводится к зна- 
нию всех мест, в которые требуется внести изменения. 

Глобальные данные образуют связывание и в том случае, если дело доходит 
до разделения прикладного кода. 

Из повторного использования кода было извлечено немало выгод. Как пока- 
зывает наш опыт, повторное использование вряд ли станет основной заботой 
при создании кода, но осмысление возможности сделать код повторно исполь- 
зуемым должно стать важной частью процедуры программирования. Делая свой 
код повторно используемым, вы снабжаете его ясным интерфейсом, развязывая 
его с остальным кодом. Это дает возможность извлекать метод или модуль, не 
таща за собой все остальное. А если в вашем коде применяются глобальные дан- 
ные, то становится трудно отделять их от всего остального. Такое затруднение 
можно обнаружить при написании модульных тестов для проверки кода, в ко- 
тором применяются глобальные данные. Чтобы создать глобальную среду лишь 
с целью выполнить тест, придется написать немало подготовительного кода. 


Избегайте глобальных данных 


Синглтоны также являются глобальными данными 


В предыдущем разделе мы осторожно вели речь о глобальных данных, а не 
о глобальных переменных. Дело в том, что разработчики нередко заявляют нам 
следующее: “Послушайте! Нет никаких глобальных переменных — я обернул их 
в данные экземпляра в объекте синглтона или глобальном модуле”. 

Но если у вас имеется синглтон с набором экспортируемых переменных эк- 
земпляра, то это все равно будут глобальные данные — просто с более длинны- 
ми именами. 

Так что ваши коллеги возьмут этот синглтон и скроют все данные за мето- 
дами. Вместо того чтобы писать СопЁ19.1о4 1еу\е1, они организуют вызов 
метода СопЁ:ід.10о9 Іеуе1 () или СопЁід.деІодІеуе1 (). Это, конечно, 
лучше, поскольку означает, что ваши глобальные данные скрывают информа- 
цию. И если вы решите изменить представление уровней протоколирования, то 
сможете сохранить совместимость, взаимно преобразуя новые и прежние уров- 
ни в АРІ конфигурирования приложения. Но множество данных конфигурации 
у вас все равно останется лишь одно. 
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Глобальные данные включают в себя внешние ресурсы 


Любой изменяемый внешний ресурс считается глобальными данными. Если 
в вашем приложении применяется база данных, хранилище информации, фай- 
ловая система, АРІ службы и т.д., вы рискуете попасть в ловушку глобализации. 
И в этом случае решение состоит в том, чтобы заключать такие ресурсы в обо- 
лочку кода, который вы контролируете. 


Если данные настолько важны, чтобы быть глобальными, 
заключите их в оболочку АРІ 


НАСЛЕДОВАНИЕ УСУГУБЛЯЕТ СВЯЗЫВАНИЕ 


Злоупотребление наследованием, когда один класс наследует состояние и по- 
ведение другого класса, оказывается настолько важным вопросом, что ему пос- 
вящен отдельный раздел “Тема 31. Налог на наследование” далее в этой главе. 


ВСЕ ДЕЛО В ИЗМЕНЕНИЯХ 


Изменить связанный код трудно. Ведь изменения в одном месте кода могут 
иметь побочные эффекты где-нибудь в другом месте кода, а зачастую — в трудно 
обнаруживаемых местах, и выходят на свет лишь через месяц эксплуатации. 

Сохранение кода скромным, чтобы он оперировал только тем, что ему из- 
вестно непосредственно, помогает поддерживать приложения развязанными, а 
следовательно, поддающимися изменениям в большей степени. 

Другие разделы, связанные с данной темой 


® Тема 8. Сущность качественного проектирования глава 2, “Прагматичный 
подход”. 

ә Тема 9. РКУ — пороки дублирования, глава 2 “Прагматичный подход”. 

• Тема 10. Ортогональность, глава 2 “Прагматичный подход”. 

® Тема 11. Обратимость, глава 2 “Прагматичный подход”. 

® Тема 29. Манипулирование реальным миром. 

» Тема 30. Преобразовательное программирование. 

е Тема 31. Налог на наследование. 

е Тема 32. Конфигурирование. 

е Тема 33. Разрывание временного связывания, глава 6 “Параллельность”. 


® Тема 34. Общее состояние — неверное состояние, глава 6 “Параллель- 
> 
ность”, 


176 Глава 5 = Гибкость или ломкость 


» Тема 35. Акторы и процессы, глава 6 “Параллельность”. 
» Тема 36. Классные доски, глава 6 “Параллельность”. 


® Принцип “указывай, а не спрашивай” подробно рассматривается в нашей 
статье “Тће А о ЕпБирріпр” (Искусство внесения программных ошибок), 
опубликованной в бойаге Сопѕітисіїіот за 2003 г. 


МАНИПУЛИРОВАНИЕ РЕАЛЬНЫМ МИРОМ 


“События не происходят просто так: 
они созданы для этого”. 


Джон Ф. Кеннеди 


В прежние времена, когда мы выглядели еще очень молодо, компьютеры были 
не особенно удобны в применении. Поэтому мы, как правило, организовывали 
свое взаимодействие с ними, исходя из их ограничений. 

Ныне мы ожидаем от компьютеров намного большего: они должны быть ин- 
тегрированы в наш мир, и никак иначе. А ведь наш мир довольно беспорядо- 
чен. В нем постоянно что-нибудь происходит, предметы перемещаются, а наше 
мнение меняется, поэтому разрабатываемым нами приложениям приходится 
каким-то образом согласовывать свои действия. 

В этом разделе речь пойдет о таких оперативно реагирующих на внешний 
мир приложениях. И начнем мы с понятия события. 


События 


Событие представляет собой доступность некоторой информации. С одной 
стороны, оно может возникнуть во внешнем мире, когда пользователь щелкает 
мышью на экранной кнопке или обновляется котировка акций на бирже. С дру- 
гой стороны, оно может быть внутренним, представляя собой результат завер- 
шенного вычисления или поиска. Оно может быть даже чем-то тривиальным 
вроде извлечения следующего элемента из списка. 

Независимо от конкретного источника событий, приложения будут работать 
в реальном мире лучше, если разрабатывать их таким образом, чтобы они реа- 
гировали на события. Пользователи найдут такие приложения более интерак- 
тивными, а сами приложения будут лучше пользоваться ресурсами. 

Но как разрабатывать такие приложения? В отсутствие определенного рода 
стратегии мы быстро окажемся в затруднительном положении, а наши прило- 
жения будут состоять из массы тесно связанного кода. 


3 См. по адресу ВЕЕрз : //тедіа.ргасдргод.сот/агіісІеѕ/јап 03 епроид.раѓ. 
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Рассмотрим четыре стратегии, способные оказать в этом помощь. 
1. Конечные автоматы. 

2. Проектный шаблон “Наблюдатель”. 

3. Модель “издатель-подписчик”. 


4. Реактивное программирование и потоки данных. 


Конечные АВТОМАТЫ 


Дэйв считает, что он пишет код с использованием конечных автоматов (КА) 
почти каждую неделю. Довольно часто реализация КА может состоять из пары 
строк кода, но эти строки помогают распутать целый клубок потенциальных 
затруднений. 

Пользоваться КА совсем не трудно, и тем не менее, разработчики настроены 
против них. Вероятнее всего, они считают, что это слишком сложно, что КА 
применимы только в работе аппаратных средств или что для этого придется 
воспользоваться малопонятной библиотекой. Ни одно из этих мнений неверно. 


Анатомия прагматичного конечного автомата 


Конечный автомат, по существу, является всего лишь спецификацией поряд- 
ка обработки событий. Он состоит из ряда состояний, одно из которых явля- 
ется текущим. Для каждого состояния перечисляются события, значимые для 
данного состояния. И для каждого из этих событий определяется новое текущее 
состояние системы. 

Например, приложение может получать составные сообщения из веб-сокета. 
Первое сообщение является заголовочным, за ним следует любое количество 
информационных сообщений, а далее — завершающее сообщение. Такая проце- 
дура приема сообщений может быть представлена в виде КА так, как показано 
ниже. 


информационное 
сообщение 
(данные) 


Начальное 


состояние сообщение 
с заголовком 


и 


завершающее Готово 
сообщение ° > 


х ——— Ф 


* 
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Все начинается с “начального состояния”. Если получено сообщение заго- 
ловка, происходит переход в состояние “чтение сообщения”. Если же в перво- 
начальном состоянии получено еще что-нибудь, то происходит переход (линия 
с меткой “*” (звездочка)) в состояние “ошибка”, и на этом процедура приема 
сообщений завершается. 

В состоянии “чтение сообщения” можно принимать информационные сооб- 
щения (в этом случае чтение продолжается в том же самом состоянии) или за- 
вершающее сообщение, и тогда процедура переходит в состояние “готово”. Все 
остальное вызывает переход в состояние “ошибка”. 

КА примечательны тем, что их можно выразить исключительно как данные. 
В качестве примера ниже приведена таблица, представляющая описанный ана- 
лизатор сообщений. 


= __ _ Заголовок Данные Завершение Другое 


Начальное Чтение Ошибка Ошибка Ошибка 
Чтение сообщения Ошибка Чтение Готово Ошибка 


Строки в этой таблице представляют состояния. Чтобы выяснить, что нужно 
делать, когда наступает событие, следует найти строку с текущим состоянием, 
просмотреть столбец, соответствующий событию, и на их пересечении найти 
ячейку с новым состоянием. 

Код, реализующий описанную выше процедуру, в равной степени прост, как 
показано ниже. 


еуепё/зітр1Іе зщ. гЬ 


Строка 1 ТКАМЅІТІОМЗ = { 
- іпіёіа1: {Пеааег: :геаа1па}, 
– геааіпа: {Чаба: :геааіпд, Ега11ег: :аопе}, 


Е } 


5 
= ѕіаёсе = :1п161а1 
= мһі1іе ѕіасе != :Яопе && ѕіасе != :еггог 
= 759 = де пехі пезѕаде () 
10 ѕсаёе = ТВАМЗТТТОМ$ [ѕёаёе] [м59.759 їуре] || :еггог 
= епа 


Код, реализующий переходы между состояниями, находится строке 10, где 
сначала индексируется таблица переходов — с помощью текущего состояния, а 
затем переходы из данного состояния индексируются с помощью типа сообще- 
ния. Если же соответствующее новое состояние не обнаружено, то происходит 
переход в состояние ошибки :еггог. 
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Добавление действий 


Чистый КА, наподобие рассматриваемого здесь, является анализатором пото- 
ка событий, единственным выходом которого является конечное состояние. Его 
можно наполнить действиями, инициируемыми при определенных переходах. 

Например, может возникнуть потребность извлечь все строки из исходного 
файла. Отдельная строка состоит из текста, заключенного в кавычки, тогда как 
знак обратной косой черты в строке экранирует следующий символ, а следова- 
тельно, "Ідпоге \"ацобеѕ\"" — единая строка. Ниже приведен КА, выпол- 
няющий данное действие. 


СП: что-то иное 


в до: добавить к результату 
С ==" СП == 
40: начальный до: добавить 
результат к результату 


в строке 
символ 


си: любой символ 
д0: добавить 
к результату 


о: конечный 
результат 


На этот раз каждый переход помечается двумя метками. Верхняя метка обоз- 
начает событие, инициирующее переход, а нижняя — действие, предпринимае- 
мое для смены состояний. 

Все это можно выразить в табличном виде, как и в предыдущем примере. Но 
на этот раз каждая ячейка таблицы содержит двухэлементный список, состоя- 
щий из следующего состояния и наименования действия. 


еуепё/зёгіпдз Ем. гЬ 


ТВАМ$ТТТОМ$ = { 


# текущее состояние новое состояние выполняемое действие 
-----–-–-–-–-–- –-–-–-–-–--–----–- 
ІооК Ғог ѕігіпад: { 
И => [ :іп зігіпд, :ѕіагі пеи ѕігіпд], 
: аеҒаціЄ => [ :100К Гог 5ігіпа, :ідпоге], 


}, 


10:55194 


ти! ИС 979) о етее :Ғіпіѕһ соггепі $6г1п9], 
АА => [ :сору пехї спаг, :ада сиггепі іо 3%г1п9], 
:аеҒац1+ 5 | 519, :ааа соггепіё іо ѕігіпд], 


, 
сору пехї сһаг: { 
:аеҒаџії =>: тм: 5ЕтіВЯ; :ааа соггепіё о ѕігіпд], 
4 
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Здесь была добавлена возможность указания перехода по умолчанию, пред- 
принимаемого в том случае, если событие не совпадает ни с одним из других 
переходов из данного состояния. А теперь рассмотрим соответствующий код: 


еуепі/зіёгіпдз Ёзтм.гЬ 


зае = :1ооКк Еог ѕїгіпд 
гези1 = [] 


мр11е сһ = 5ТрІМ.одеіс 
<фаее, асііоп = ТКАМЗТТТОМ$ [ з6аёе] [ср] || 
ТВАМЗТТТОМ$ [ $сасе] [: 4аеЁац1*] 
сазе асііоп 
"реп :ідпоге 
мреп :ѕіагі пем ѕігіпд 
гези1 = [] 
мһеп :ада соггепі бо ѕігіпд 
геѕиіё << сһ 
мһеп :Ғіпіѕһ сиггепі ѕігіпд 
риз геѕиіє.јоіп 
епа 
епа 


Данный пример похож на предыдущий в том отношении, что события (сим- 
волы во входных данных) обрабатываются в цикле, инициируя переходы. Но 
здесь делается нечто большее, чем в предыдущем коде. Результатом каждого пе- 
рехода является как новое состояние, так и наименование действия. Это наиме- 
нование используется для того, чтобы выбрать выполняемый код, прежде чем 
вернуться в начало цикла. 

Несмотря на то что рассматриваемый здесь код довольно прост, он исправно 
выполняет свою функцию. Имеется немало других вариантов: воспользоваться 
в таблице переходов анонимными функциями или указателями на функции для 
выполнения отдельных действий; заключить код, реализующий конечный авто- 
мат, в отдельный класс со своим состоянием и т.д. 

Нечего и говорить, что переходы во все состояния должны быть обработаны 
одновременно. Так, если требуется пройти процедуру регистрации пользовате- 
ля в приложении, то по мере ввода им данных, проверки правильности адреса 
его электронной почты, согласования 107 различных предупреждений, которые 
приложение должно выдавать в оперативном режиме, и прочего, вероятнее все- 
го, потребуется осуществить целый ряд переходов. Чтобы удовлетворить подоб- 
ного рода требованиям к последовательности выполняемых действий, целесооб- 
разно хранить состояние во внешней памяти и пользоваться им для приведения 
конечного автомата в действие. 


Конечные автоматы как отправная точка 


Конечные автоматы находят ограниченное применение у разработчиков, по- 
этому нам хотелось бы побудить вас искать возможности для их применения. 
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Тем не менее они не решают все затруднения, возникающие в связи с обработ- 
кой событий. Поэтому перейдем к рассмотрению некоторых других способов 
разрешения затруднений, возникающих при обработке событий. 


ПРОЕКТНЫЙ ШАБЛОН “ОБОЗРЕВАТЕЛЬ” 


В шаблоне “Обозреватель” (ОЪ5егуег) имеется источник событий, называе- 
мый наблюдаемым объектом, а также список клиентов, называемых наблюдате- 
лями и заинтересованных в событиях из этого источника. 

Обозреватель регистрирует свой интерес у наблюдаемого объекта, как пра- 
вило, передавая ссылку на вызываемую функцию. Соответственно, когда насту- 
пает событие, наблюдаемый объект обходит список наблюдателей и вызывает 
функцию, которая была передана ему каждым наблюдателем. При вызове дан- 
ной функции событие передается ей в качестве параметра. 

Ниже приведен пример реализации шаблона “Обозреватель” на языке ВиБу. 
В частности, модуль Тегтіпаіог служит для прерывания работы приложения. 
Но прежде чем это сделать, он уведомляет всех своих обозревателей о том, что 
приложение собирается завершиться“. Они могут воспользоваться этим уведом- 
лением, чтобы очистить временные ресурсы, зафиксировать данные и т.д. 


еуепі/ођзегуег . гЬ 


поач1е Тегтіпаіог 
САШВАСК$ = [] 


де# ѕе1#.гедіѕіег (са11раск) 
САЬТВАСК$ << са11раск 
епа 


де# зе1Ё.ех1{ (ехії зіаіиѕ) 
САІВАСК5.еасһ { |са11раск| са11раск. (ехії ѕіаїцѕ) } 
ехії! (ехії ѕёаіциѕ) 
епа 
епа 


Тегтіпаіог.гедіѕіег (-> (ѕбаёцѕ) { риёѕ "са11раск 1 ѕееѕ #{ ѕёаёцѕ}" }) 
Тегтіпаіог.гедіѕіег (-> (ѕіёаёиѕ) { риіѕ "са11раск 2 зеез #{ѕбаїіцѕ}" }) 


Тегтіпаіог.ехіії (99) 


$ гору еуепі/орзегуег.гЬ 
са11расКк 1 ѕееѕ 99 
са11раск 2 зеез 99 


Для создания наблюдаемого объекта требуется не так уж и много кода. Для 
этого достаточно разместить сначала ссылки на функции в списке, а затем вы- 
звать эти функции, когда наступит событие. Это характерный пример того 


4 
Нам, конечно, известно, что такая возможность уже реализована в языке Киђу с помо- 
щью функции а ехії (). 
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момента, когда не следует пользоваться библиотекой. Шаблон наблюдателей 
и наблюдаемого объекта применялся десятилетиями и сослужил нам добрую 
службу. Его применение особенно преобладает в системах с пользовательским 
интерфейсом, где обратные вызовы служат для извещения о том, что в прило- 
жении произошло какое-то взаимодействие. 

Но шаблону “Обозреватель” присущ следующий недостаток: он вносит свя- 
зывание, поскольку каждый наблюдатель должен регистрироваться у наблюда- 
емого объекта. А поскольку в типичной реализации обратные вызовы обраба- 
тываются наблюдаемым объектом синхронно, он может вносить узкие места в 
производительность системы. Этот недостаток устраняется с помощью рассмат- 
риваемой ниже стратегии “издатель-подписчик”. 


МодЕЛЬ “ИЗДАТЕЛЬ-ПОДПИСЧИК” 


Эта модель обобщает шаблон “Обозреватель” и в то же время устраняет не- 
достатки связывания и производительности. Модель “издатель-подписчик” со- 
стоит из издателей и подписчиков, соединяемых вместе через каналы, которые 
реализуются в отдельном коде: иногда — в библиотеке, порой — в процессе, а 
иной раз — в распределенной инфраструктуре. Все эти подробности реализа- 
ции скрыты от прикладного кода. 

У каждого канала имеется свое имя. Подписчики регистрируют свой инте- 
рес в одном или нескольких этих именованных каналах, куда издатели выводят 
свои события. В отличие от шаблона “Обозреватель”, общение между издателем 
и подписчиком происходит за пределами прикладного кода и потенциально — 
асинхронно. 

Несмотря на то что самую элементарную систему “издатель-подписчик” 
можно реализовать самостоятельно, это вряд ли потребуется. Большинство 
поставщиков облачных услуг предоставляют услуги типа “издатель-подписчик’, 
позволяя подключать приложения по всему миру. В каждом распространенном 
языке программирования может быть хотя бы одна библиотека типа “издатель- 
подписчик”. 

Модель “издатель-подписчик” является удобной технологией развязывания 
обработки асинхронных событий. Она позволяет добавлять и заменять код, 
потенциально — во время выполнения конкретного приложения, не изменяя 
существующий код. Ее недостаток заключается в том, что она затрудняет вы- 
яснение происходящего в системе, где интенсивно применяется данная модель. 
В частности, глядя на издателя, нельзя сразу же увидеть, какие именно подпис- 
чики связаны с конкретным сообщением. 

В сравнении с шаблоном “Обозреватель” модель “издатель-подписчик” слу- 
жит характерным примером сокращения нежелательного связывания абстра- 
гированием через общий интерфейс (т.е. канал). Тем не менее она, по сущест- 
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ву, остается не более чем системой передачи сообщений. Для создания систем, 
реагирующих на события, возникающие в определенном сочетании, требуется 
нечто большее, чем передача сообщений. Поэтому рассмотрим далее способы, 
позволяющие внести измерение времени в обработку событий. 


РЕАКТИВНОЕ ПРОГРАММИРОВАНИЕ, ПОТОКИ ДАННЫХ И СОБЫТИЯ 


Если вам приходилось когда-нибудь пользоваться электронными таблицами, 
то вы уже в какой-то степени знакомы с реактивным программированием. Так, 
если в одной ячейке электронной таблицы содержится формула, ссылающая- 
ся на другую ячейку, то обновление последней приведет к обновлению первой. 
Можно сказать, что одни значения реагируют на изменения других значений, 
которые в них используются. 

Имеется немало каркасов, способных оказать помощь в организации такого 
рода реакционности на уровне данных. Так, в области браузеров наиболее рас- 
пространены каркасы Кеасі и Уче.]$, реализованные на языке ЈауаЅсгірї, хотя эти 
сведения могут устареть ко времени выхода настоящего издания в свет. 

Очевидно, что события могут быть также использованы для запуска реакций 
в прикладном коде, хотя подключить их не так-то просто. Именно здесь и при- 
годятся потоки данных, которые позволяют трактовать события так, как если 
бы они были коллекцией данных. Это похоже на список событий, расширяю- 
щийся по мере наступления новых событий. Прелесть такого подхода состоит 
в том, что потоки данных можно обрабатывать таким же образом, как и любую 
другую коллекцию, манипулируя, комбинируя, фильтруя и делая все остальное, 
что, как хорошо нам известно, делается с данными. Потоки данных можно даже 
объединять с обыкновенными коллекциями. Они могут быть асинхронными, а 
это означает, что в прикладном коде появляется возможность реагировать на 
события по мере их наступления. 

Текущие исходные условия для обработки реактивных событий определя- 
ются на веб-сайте по адресу ВЕЕр: / /геасЕ1уех. 10, где устанавливается ряд 
не зависящих от конкретного языка принципов и документов для некоторых 
типичных реализаций. Так, в приведенном ниже примере используется библио- 
тека Вх] для сценария на языке Јауа$сгірі. 


еуел%Е/гх0/1паех. 3 


проге * аз Орѕегуар1е ком 'гх]5' 
проге { 1од\Уа1аез } Егом "../гхсоппоп/1оддег.7 5" 


1еЕ апіта15 = Орѕегуар1іе.о# ("ап®", "рее", "са", "аод", "е1к") 
Іе+ їіскег Орѕегуар1іе.іпіегуа1 (500) 
1её сопріпеа Орѕегуаріе.2ір (апіта1іѕ, їіскег) 


сопріпеа. ѕирѕсгіре (пехі => 10о9дУа1цезѕ (Ј503.ѕігіпдіҒу (пехі))) 
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В данном коде применяется простая журнальная функция”, вводящая элемен- 
ты в список, отображаемый в окне браузера. Каждый такой элемент снабжается 
отметкой времени в миллисекундах, прошедших с момента запуска программы. 
Ниже показано, что именно выводится на экран из данного кода. 


а а 


Е я 


ГАНЕ" 07 


% 
10 


ве" 42 


Обратите внимание на отметки времени. В частности, через каждые 500 мс 
из потока данных получается одно событие. Каждое событие содержит поряд- 
ковый номер, формируемый наблюдаемым объектом і піегуа1, а также на- 
звание следующего животного, выбираемое из списка. В окне браузера реально 
наблюдается появление протокольных строк через каждые полсекунды. 

Потоки данных, как правило, заполняются по мере наступления событий, а 
это подразумевает, что наблюдаемые объекты могут заполнять их параллель- 
но. В приведенном ниже примере кода сведения о пользователях извлекаются 
из удаленного сайта. Для этой цели используется веб-сайт, общедоступный по 
адресу рз: / /геагеѕ.іп и предоставляющий открытый прикладной интер- 
фейс КЕЅТ АРІ. Частью этого прикладного интерфейса можно воспользоваться, 
чтобы извлечь данные о конкретном (вымышленном) пользователе, выполнив 
запрос по методу СЕТ и условию ип5ег$5/"1а". В данном коде извлекаются све- 
дения о пользователях с идентификаторами 3, 2 и 1. 


еуепе/гх1 /1паех. 3 


1проге * аз Орѕегуар1е Ёргот 'гх)5' 


ітрогё { пегаеМар } Егот 'гх)з/орега®огз' 
1прог®е { ајах } Его 'гхјѕ/ајах'! 
проге { ]1оа\/а1аез } Ғгот "../гхсоптоп/1оадег. 5" 


1еЕ озегз = Орѕегуар1іе.оЁ (3, 2, 1) 
Іеї гезо1е = иѕегѕ.ріре (мегаеМар ( (иѕег) => 
ајах.деЁј50М ('ВЕЕрз: //геагез.1п/ар1/изегз/${изег}')) 


5 См. по адресу Һірѕ: //педіа.ргадргод. сомп/ёіё1еѕ/ірр20/ сойе/еуепі / 
гхсоппоп/1оддег.јѕ. 
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геѕи1ї . ѕирѕсгіре ( 
геѕр => 1оч\Уа1ае$ (Ј50№.ѕігіпаі#у (гезр.Чафа)), 
егг => сопзо1е.еггог (ЈЅОМ.ѕігіпаіЁу (егг)) 


) 


Внутренние подробности реализации данного кода не так важны. Более при- 
влекателен результат его выполнения: 


еее п томе" ОВ чнае усне рено тль имруз аеру УЕА оь еу Гена 
арти орн Ааа Тоту АНА У ЗИ еа АГ 
а Е АТ ем = Я а 


87 


{"190":2,"Ғітгѕї пате": "Јапеї', "1аѕї_пате" : "Меауег", "амаї 


{"10":1,"Ғігѕї пате" : "беогее" , "1аѕї пате" : "В1иїһ", "ама\ 


{"14":3,"Ғіг5ї1 пате": "Етта", "1аѕї пате" : "Мопе", "ауаїаг" 


е чо 2254 ГА х. № х пыга < 2 
ЗИ БО АИ А Васы 5 Е Е асаре та АД 
А оа нс «айога ДАНАДАН Ла О знав рыта р АЈ а АУС Оа даа Аалай Аба ета їе унтаа асов 6 


Обратите внимание на отметки времени. В частности, три запроса или три 
отдельных потока данных обрабатываются параллельно. Так, первый запрос по 
идентификатору 2 был обработан через 82 мс, а два последующих запроса — 
еще через 50 и 51 мс соответственно. 


Потоки событий как асинхронные коллекции 


В предыдущем примере список идентификаторов пользователей (в наблюда- 
емом объекте иѕегѕ) был статическим, хотя он совсем не обязательно должен 
быть таковым. Собирать подобные сведения, вероятно, требуется в том случае, 
когда пользователи регистрируются на веб-сайте. Для этого достаточно иници- 
ировать наблюдаемое событие, содержащее идентификатор пользователя, когда 
создается сеанс его работы на сайте, а затем воспользоваться этим наблюдаемым 
событием вместо статического. И тогда подробные сведения о пользователях 
будут извлекаться по мере получения их идентификаторов и предположительно 
сохраняться где-нибудь. 

Это весьма эффективная абстракция, поскольку она избавляет от необходи- 
мости думать о времени как о чем-то, чем приходится управлять. Потоки собы- 
тий обобщают синхронную и асинхронную обработку в общем удобном АР]. 


СоБЫТИЯ ВЕЗДЕСУЩИ 


События присутствую везде. Одни из них более очевидны: щелчок кнопкой 
мыши, истечение срока действия таймера, а другие — менее очевидны: регис- 
трация пользователя, совпадение строки в файле с шаблоном. Но независимо 
от конкретного источника событий, код их обработки может более оперативно 
реагировать и стать лучше развязанным, чем более линейный его аналог. 
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Другие разделы, связанные с данной темой 


ә Тема 28. Развязывание. 
• Тема 36. Классные доски, глава 6 “Параллельность’. 


Упражнения 


19. В разделе, посвященном конечным автоматам, упоминалось, что обобщен- 
ную реализацию конечного автомата можно переместить в отдельный класс. 
Для инициализации этого класса, вероятно, придется передать его конструк- 
тору таблицу переходов и первоначальное состояние конечного автомата. 
Попробуйте реализовать компонент, извлекающий подобным способом сим- 
вольную строку. 


20. Какая из рассмотренных в этом разделе технологий (а возможно, их опреде- 

ленное сочетание) окажется пригодной в следующих случаях: 

® если в течение пяти минут получены три события о выходе из строя сетево- 
го интерфейса, непременно уведомить об этом обслуживающий персонал; 

® если после захода солнца обнаруживается движение сначала внизу, а затем 
вверху лестницы, включить лестничное освещение; 

ә требуется уведомить различные системы учета о выполнении заказа; 

ә чтобы выяснить, имеет ли клиент право на заем, приложение должно от- 
править соответствующие запросы трем серверным службам, ожидая от 
них ответов. 


В О Е О О НАА АА МОТ АО вы 


ПРЕОБРАЗОВАТЕЛЬНОЕ ПРОГРАММИРОВАНИЕ 


“Если вы не в состоянии описать то, что делаете, как 
процесс, значит, вы не знаете, что делаете”. 


У Эдвардс Деминг? 


Все программы преобразуют входные данные в выходные. Но когда мы рас- 
суждаем о проектировании, то редко задумываемся об организации преобразо- 
ваний. Вместо этого мы больше беспокоимся о классах и модулях, структурах 
данных и алгоритмах, языках и каркасах приложений. 

Мы считаем, что такая сосредоточенность на коде нередко приводит к тому, 
что из виду упускается самое главное, поэтому необходимо вернуться к тому, 
чтобы рассматривать программы как нечто, преобразующее входные данные в 
выходные. И если поступить именно так, то многие беспокоившие нас ранее 
подробности просто улетучатся, структуры данных станут более понятными, 
обработка ошибок — более согласованной, а связывание сведется к минимуму. 


6 үү. Еамага$ Реп11$ — американский ученый -статистик ХХ века. — Примеч. пер. 
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Чтобы начать исследование данного вопроса, вернемся во времени назад в 
1970-е годы, чтобы попросить программирующего в операционной системе (піх 
написать для нас программу, в которой перечисляются пять самых длинных 
файлов в дереве каталога, где под словом “самый длинный” подразумевается 
наличие в файле наибольшего количества строк. 

Можно было бы предположить, что этот программирующий откроет текс- 
товый редактор и начнет набирать исходный код на языке С. Но он не сделает 
этого, поскольку мыслит категориями того, что имеется (дерева каталогов), а 
также того, что требуется (списка файлов), т.е. входных и выходных данных. И с 
этой целью он сядет за терминал и наберет на нем последовательность команд, 
аналогичную приведенной ниже. 


$ Ғіпа . -вуре Е | хагдз мс -1 | зог -п | +аі1 -5 


В этой последовательности команд выполняются следующие преобразова- 
НИЯ: 


• Ғіпа . -ёуре Е — направить список всех файлов (параметр -%уре Е) из 
текущего каталога (.) или его подкаталогов в стандартный поток вывода. 


е хагдз мс -1 — ввести этот список из стандартного потока ввода и упоря- 
дочить их таким образом, чтобы передать в качестве аргументов команде 
мс -1, которая подсчитает количество строк в каждом из файлов как сво- 
их аргументов и направит полученный результат вместе с именем файла в 
стандартный поток вывода. 


е зог -п — отсортировать данные из стандартного потока ввода, прини- 
мая во внимание, что каждая строка начинается с числа (параметр -п), 
направив полученный результат в стандартный поток вывода. 


ө $а1]1 -5 — взять данные из стандартного потока ввода и направить в 
стандартный поток вывода только последние пять строк. 


Если выполнить описанную выше последовательность команд в каталоге с 
файлами глав данной книги, то в конечном счете будет получен следующий ре- 
зультат: 

470 „./кезЕ Фо рџі1а.рт1 
487 ./арс.рті 
719 ./аота1п_1апачадез .рт1 


727 ./агу.ртіІ 
9561 Софа] 


В последней строке приведенного выше результата указано общее количес- 
тво строк во всех обработанных, а не только в показанных файлах, поскольку 
именно таким образом действует команда мс. Эту строку можно исключить из 
результата, запросив еще одну строку из команды +а11, а затем проигнориро- 
вав последнюю строку: 
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$ Ғіпа . -+уре # | хагдз мс -1 | зогё -п | $а11 -6 | Һеаа -5 
470 ./аерцд.ртмі 
470 ./Сеѕі бо рџоі1а.рт1 
487 ./арс.рті 
719 ./аота1п_1апаиадез .рм1 
727 ./агу.рм1 


Проанализируем этот результат с точки зрения данных, проходящих потоком 
через все стадии процесса их обработки. Первоначальное требование вывести 5 
файлов с наибольшим количеством строк превращается в целый ряд преобра- 
зований, перечисленных ниже и далее на рис. 5.1. 


имя каталога 
— список файлов 

—> список с количеством строк 

— отсортированный список 

—› пять файлов с наибольшим количеством строк плюс общий итог 


ә» пять файлов с наибольшим количеством строк 


ИМЯ 


каталога 
—ы— В» | 


имена файлов \__ > 


список файлов с ! 
количествами строк 


список файлов, отсортированный | | 
по количеству строк — 


последние 5 файлов | ‚З 
плюс общий итог 


у 
последние 
5 файлов 


Рис. 5.1. Конвейерное выполнение команды Е1па в виде 
последовательности преобразований 


Это очень похоже на промышленный сборочный конвейер, на вход которого 
подается сырье (исходные данные), а на выходе получается готовая продукция 
(результаты обработки исходных данных). Именно так мы и предпочитаем рас- 
сматривать весь код. 


Программирование имеет отношение к коду, 
а программы — к данным 
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ОБНАРУЖЕНИЕ ПРЕОБРАЗОВАНИЙ 


Иногда, чтобы найти преобразования, проще всего начать с требования и 
определить сначала его входные и выходные данные, а затем функцию, пред- 
ставляющую программу в целом. После этого можно выяснить стадии преобра- 
зования входных данных в выходные. Это метод нисходящего проектирования. 

Допустим, требуется создать веб-сайт для тех, кто увлекается играми в слова, 
находя среди них все слова, которые могут быть составлены из определенно- 
го ряда букв. В качестве входных данных здесь служит ряд букв, а в качестве 
выходных данных — список слов, составленных из трех, четырех и большего 
количества букв, как показано ниже. 


Ем, Ар ЕЕ, У 
слово "1уу1п" преобразуется в слова -» 4 => 1п1у, 11пу, уіпу 
5 => уіпу1 


(Все это действительно слова — по крайней мере, в соответствии со словарем тасО$.) 


Вся хитрость в данном примере состоит только в наличии словаря, группирую- 
щего слова по сигнатуре, выбранной таким образом, чтобы все слова, состоящие 
из одних и тех же букв, имели одинаковую сигнатуру. Простейшая функция сиг- 
натуры состоит лишь в отсортированном списке букв в слове. И это дает возмож- 
ность найти входную символьную строку, сформировав сначала для нее сигнату- 
ру, а затем найти в словаре, если удастся, все слова с одинаковой сигнатурой. 

Таким образом, средство поиска анаграмм (т.е. слов, получаемых путем пе- 
рестановки букв) можно разбить на процесс, состоящий из четырех отдельных 
преобразований, как показано ниже. 


Стадия Преобразование Образец данных 
0 Первоначальные входные данные "у1уіп" 
1 Все сочетания из трех или более букв уіп, уіу, уі1, упу, уп1, уу1, іпу, 


іп1, 1у1, пу1, уіпу, уіп1, уіу1, 
упуі, іпу1, уіпу1 


2 Сигнатуры сочетаний іпу, іуу, 11У, пуу, 1пу, Іуу, іпу, 
і1п, 11у, 1пу, іпуу, і1пу, і1уу, 
1пуу, 11пу, 1]пуу 


3 Список всех слов в словаре, совпадаю- іуу, уіп, пі1, 1іп, уіпу, Ііпу, 
щих с любыми из указанных сигнатур іп1у, уіпу1 
4 Группировка слов по длине 3 => іуу, 1іп, пі1, уіп 


4 => іп1Іу, 11пу, уіпу 
5 => уіпуІ 
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Преобразования по нисходящей 


Итак, начнем с рассмотрения первой стадии описываемого здесь процесса, 
на которой берется исходное слово и из него составляется список всех сочета- 
ний из трех или более букв. Эта стадия выражается в виде приведенного ниже 
перечня преобразований. 


Стадия Преобразование Образец данных 

1.0 Первоначальные входные данные "муіпу1" 

1.1 Преобразование символов у, і, п, у, 1 

1.2 Получение всех подмножеств [], [У], [2], ... [“,21, [м7], [МУ], ... 
[У,1,п], [%,1,У],... [у,п,у,1], [1,п,у,1], 
[у,1,п,у,1] 

1.3 Только те сочетания, которые состоят [%у,і,п], [у,і,у], ... [1,п,у,1], 

более чем из трех символов [у,1,п,у,1] 
1.4 Преобразование обратно [уіп,уіу, ... іпу1,уіпу1] 


в символьные строки 


Итак, мы достигли момента, когда можно без труда реализовать каждое пре- 
образование непосредственно в коде (используя в данном случае язык Е]іхіг). 


Ғопсёіоп-ріре1іпез/ападгатз/1ір/ападгатѕ.ех 


дӢеёр а11 ѕирѕеіѕ 1опдег іһап іһгее сһагасіегѕ (мога) до 
мога 
|> ЗЕг1па.соаеро1пе$ () 
|> Сом. зирзес$ () 
|> Ѕегеатм.ЁіІіег (Ёп ѕирѕеї -> Іепабһ (ѕирѕеї) >= 3 епа) 
|> 5Егеам.тар (61150.10 $6 г1па (&1)) 

епа 


Назначение оператора |> 


Как и во многих других функциональных языках, в ЕЙхи имеется конвейер- 
ный оператор, иногда еще называемый подающим конвейером (їогмахӣ ріре), или 
просто конвейером (ріре)'. Его основное назначение — взять значение, указанное 
слева от него, и вставить его в качестве первого параметра функции справа, так 
что строка кода 


"у1пу1" |> бЅїгіпа.сойероіпіѕ |> Сопр.ѕирѕеѓіѕ () 
аналогична приведенной ниже. 

Сотр . ѕирѕеїѕ (Ѕігіпдо. сойероіпіёѕ ("уіпу1")) 
7 По-видимому, первое употребление символов | > для обозначения канала относит- 
ся к 1994 году, когда велась дискуссия о языке І$0бее/МІ, архивные материалы ко- 


торой см. по адресу Һ№їрѕ://61095.тѕап.тісгоѕоЁё. сот/ аѕуте/2011/05/17/ 
агсһео1одіса1-ѕетіоіісѕ-Ећһе-рігіһ-о#-ёһе-ріре1іпе-ѕутро1-1994/. 
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В других языках конвейерное значение может быть вставлено в качестве пос- 
леднего параметра следующей функции. Хотя это зависит, главным образом, от 
стиля организации встроенных библиотек. 

На первый взгляд, это всего лишь синтаксическое удобство, но конвейерный 
оператор на самом деле является важной возможностью мыслить иначе. При- 
менение конвейера, по существу, означает автоматическое мышление категори- 
ями преобразования данных. Всякий раз, когда в исходном коде встречается 
оператор |>, он обозначает место, где данные перемещаются потоком от одного 
преобразования к другому. 

Нечто подобное конвейерному оператору имеется во многих других языках. 
Так, в языках Ет, Е# и $УЙ имеется аналогичный оператор |>, ав СіІојиге — 
операторы -> и ->>, которые действуют несколько иначе, тогда как в языке В — 
оператор %>%. В языке НазКе| имеются не только готовые конвейерные опера- 
торы, но и возможность легко объявлять новые. На момент написания данной 
книги велась полемика по поводу внедрения конвейерного оператора |> ив 
языке ЈауаЅсгірї. 

Если в применяемом вами языке поддерживается нечто подобное, то вам по- 
везло. В противном случае см. далее врезку “Отсутствие конвейеров в языке Х". 
Впрочем, обратимся непосредственно к коду. 


Продолжим преобразование... 


Теперь рассмотрим вторую стадию описываемого здесь процесса, реализу- 
емого в основной программе, где подмножества преобразуются в сигнатуры. 
И на этот раз речь пойдет о простом преобразовании, в результате которого 
список подмножеств становится списком сигнатур: 


Стадия Преобразование Образец данных 
2.0 Первоначальные входные данные уіп, УЗу, ... іпу1, уіпу1 
2.1 Преобразование в сигнатуры іпу, іуу ... і1пу, іп1уу 


Код Еііхіг, реализующий такое преобразование, достаточно прост, как можно 
убедиться: 


Ғопсёіоп-ріре1іпез/ападгатз/1ір/ападгатз.ех 


ЧеЁёр аѕ џпідџе ѕідпаїіогеѕ (ѕирѕеіѕ) до 
ѕирѕеїзѕ 
|> 5Егеам.тар (&рісііопагу.зѕідпаіцге оЁ/1) 
епа 
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Теперь преобразуем этот список сигнатур, чтобы отобразить каждую из них 
на список известных слов одинаковой сигнатуры или присвоить пустое значение 
п11 в отсутствие таких слов. После этого придется удалить все пустые значения 
пі1 и свести все вложенные списки в единый список. 


Ғопсііоп-ріре1іпеѕ/ападгатѕ/1іђ/ападгатз .ех 


ЧеЁр Ғіпа іп аісііопагу (ѕідпаіџгеѕ) до 
ѕісдпаіцгеѕ 
|> бЕгеам.мар (&рісёіопагу.1оокир ру ѕідпаіџге/1) 
|> ЗЕгеам.гедес® (&15 пі1/1) 
|> ЅЕсеатм.сопсаї (& (&1)) 
епа 


На четвертой стадии группирования слов по длине выполняется еще одно 
простое преобразование списка в отображение, где ключами являются длины 
слов, а значениями — все слова данной длины: 


Ғопсёіоп-ріре1іпеѕ /ападгатѕз/1ір/ападгатзѕ.ех 


ЧеЁР чгопр ру Іепдіћ (могаѕ) ао 
мога5 
|> Епим. $0: () 
|> Епим.агопр ру (&5Ег1па.1епаев/1) 
епа 


Собирая все вместе 


Мы реализовали в коде каждое отдельное преобразование, теперь самое вре- 
мя собрать их все вместе в одной главной функции, приведенной ниже. 


Еапс&1оп-рзре]1пез/ападгат$/11Ь/ападгатз .ех 


ЧеЁ ападгапѕ іп (мога) ао 
мога 
|> а11 ѕирѕеёѕ Іопдег Пап іһгее сһагасіегѕ () 
|> аѕ ипідце ѕідпаїигезѕ () 
|> Ғіпа іп аісіёіопагу () 
|> дкгоир ру 1Іепоёћ () 
епа 


Проверим работоспособность данной функции следующим образом: 


1ех (1) > Ападгат$ .ападгамз іп "1Іууіп" 
5 { 

З = му", а аса "уіп" ] Я 
4 = Гоу "ту, "уіпу"] м 
9 


> 
> ["міпу1"] 
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ОТСУТСТВИЕ КОНВЕЙЕРОВ В ЯЗЫКЕХ — 


Конвейеры применялись уже давно, но только в узкоспециализированных 
языках. И лишь недавно они перекочевали в ведущие языки программиро- 
вания, хотя во многих распространенных языках поддержка данного поня- 
тия по-прежнему отсутствует. 


Преимущество мышления категориями преобразований заключается в том, 
что оно не требует знания синтаксиса конкретного языка. Это скорее при- 
нцип проектирования. И хотя этот принцип означает конструирование кода 
в виде преобразований, они записываются в виде последовательности опе- 
раторов присваивания, как показано ниже. 


сопзі сопіепі 
соп 1іпезѕ 
соп гези1{ 


РіЈе.геаа (Е11е папе); 
Ғіпа таєсһіпд 1іпеѕ (сопіепі, раефегп) 
сгипсаее 11пез (1іпез) 


І 


Несмотря на то что это трудоемкий способ, он все же вполне работоспособен. 


В ЧЕМ ЖЕ ЗДЕСЬ ПОЛЬЗА 


Рассмотрим тело главной функции снова: 


мога 

|> а11 ѕорѕеѕ 1опдег «Пап ©һгее сһагасіегѕ () 
|> аз ип1аце ѕідпаіигеѕ () 

|> #іпа іп аісііопагу () 

|> агоир ру 1Іепдїћ () 


Это всего лишь цепочка преобразований, необходимых для удовлетворения 
исходного требования, причем каждое из них принимает входные данные из 
предыдущего преобразования и передает выходные данные следующему преоб- 
разованию. И это как можно более точно приводит непосредственно к коду. 

Но дело здесь обстоит несколько сложнее, чем кажется на первый взгляд. 
Так, если у вас есть навыки объектно-ориентированного программирования, то 
ваши рефлексы требуют скрывать данные, инкапсулируя их в объектах, которые 
обмениваются ими, изменяя состояние друг друга. А поскольку это приводит к 
внесению в программу связывания, то служит веским основанием считать объ- 
ектно-ориентированные системы с трудом поддающимися изменениям. 


Не накапливайте состояние, а передавайте его по кругу 


В преобразовательной модели дело меняется коренным образом. Вместо не- 
больших массивов, распределенных по всей системе, данные следует уподобить 
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в рассуждении могучей реке или потоку. Таким образом, данные становятся 
сродни функциональным возможностям, где конвейер — это последовательность 
код —> данные -> код > данные... Данные больше не привязаны к конкретной 
группе функций, как это обычно делается в определении класса. Напротив, они 
свободно представляют постепенно развертывающийся в приложении процесс 
преобразования входных данных в выходные. А это означает возможность зна- 
чительно сократить связывание, поскольку одну функцию можно использовать 
(и неоднократно) везде, где ее параметры совпадают с выходом из какой-нибудь 
другой функции. 

Впрочем, определенная степень связывания все же существует, но, как пока- 
зывает наш опыт, она легче поддается управлению, чем при объектно-ориенти- 
рованном программировании. И если вы программируете на языке с проверкой 
соответствия типов, то получите предупреждения во время компиляции, если 
попытаетесь соединить две несовместимые вещи. 


А КАК НАСЧЕТ ОБРАБОТКИ ОШИБОК 


До сих пор рассматриваемые здесь преобразования действовали в такой сре- 
де, где ничего неверного не происходит. Но как выполнить их в реальной обста- 
новке? Если можно составить лишь линейные цепочки, то как внедрить всю ту 
условную логику, которая требуется для проверки ошибок? 

Это можно сделать самыми разными способами, но все они основываются на 
следующем соглашении: значения ни в коем случае нельзя передавать от одного 
преобразования к другому в исходном виде, а вместо этого их следует заклю- 
чать в структуру (или тип) данных, где можно проверить достоверность содер- 
жащихся в них значений. Например, в языке НаѕКе]] такая оболочка называется 
Мауре, а в языках Е# и Ѕсаја — ОрЕ1оп. 

Особенности применения данного принципа зависят от конкретного языка 
программирования. Но в общем, реализовать его непосредственно в коде мож- 
но двумя способами: проверять ошибки в самих преобразованиях или же за их 
пределами. 

В языке Е]іхіг, которым мы пользовались в приведенных до сих пор примерах 
кода, отсутствует встроенная поддержка обработки ошибок при преобразовани- 
ях. Но это вполне отвечает нашим целям, поскольку нам нужно продемонстри- 
ровать реализацию такой обработки ошибок с самого начала. Нечто подобное 
должно оказаться пригодным и для программирования на других языках. 


Сначала выбирается представление 

Нам потребуется некоторое представление оболочки, т.е. структуры данных, 
содержащей значение или признак ошибки. Для этой цели можно воспользо- 
ваться структурами, но в языке Е]іхіг уже имеется следующее довольно строгое 
соглашение: функции преимущественно возвращают кортеж { : оК, значение} 
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или {:егког, причина}. Например, функция Е11е.ореп() возвращает при- 
знак : ок и идентификатор процесса ввода-вывода или же признак :еггог и код 
причины ошибки, как показано ниже. Кортежами с признаками : оК и :еггог 
можно воспользоваться в качестве оболочки, передавая результаты преобразо- 
ваний по конвейеру. 

1ех (1)> Е11е.ореп ("/еёс/раз5ма") 

{:ок, #Р1р<0.109.0>} 


іех (2) > Е11е.ореп ("/еіс/мопраі") 
{:еггог, :епоепї} 


Затем обработка ошибок выполняется в каждом преобразовании 


Итак, напишем функцию, возвращающую из файла все строки, содержащие 
заданную символьную строку, усеченную до 20 первых символов. Эту функцию 
требуется написать как преобразование с именем файла и сопоставляемой сим- 
вольной строкой в качестве входных данных, а также с кортежем, содержащим 
признак :ок и список строк или же признак :еггог и причину ошибки, в ка- 
честве выходных данных. В общих чертах такая функция должна выглядеть сле- 
дующим образом: 


Ғопсёіоп-ріре1іпез/ападгатз/1ір/дгер.ех 


её Ғіпа а11(Е11е пате, раїёегп) Яо 
ҒіЈе.геаа(#і1Іе пате) 
|> Е1па тмаёсһіпо 1іпеѕ (рае егп) 
|> Еропсаёсе 1іпеѕ () 

епа 


Здесь ошибки не проверяются явным образом, но если на любой стадии 
конвейерного процесса возвращается кортеж с признаком ошибки, то обнару- 
женная ошибка будет возвращена из конвейера, причем последующие функции 
далее не выполняются. Это делается языковыми средствами ЕЇіхіг для сопостав- 
ления с шаблоном, как показано ниже. 


Ғопсёіоп-ріре1іпез/ападгатз/1іЬ/дгер.ех 


деёр Ғіпа тассһіпд 1ілпеѕ ({:ок, сопёепі}, раёбегп) до 
сопёепі 
|> Ѕігіпа. ѕр1іё (-к/\п/) 
|> Епим. Ё11Ссег (&51гіпа.таёсћ? (&1, раёіёегп)) 
|> ок цп1іеѕѕ епріу () 
епа 


ЧеЁр Ғіпа таёсһіпод 1іпеѕ (еггог, ), до: еггог 


9 Мы допустили здесь некоторую вольность. Технически последующие функции ВЫПОЛНЯ- 
ются. Не выполняется их КОД. 
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ЧеЁр Егопсафе 11пез({ :ок, 1іпеѕ }) ао 
1іпеѕ 
|> Епом.тмар (&5 гіпа. ѕ11ісе (&1, 0, 20)) 
|> оК () 

епа 


дӢеЁр ёгопсаёе 1іпеѕ (еггог), ао: еггог 


АеЁр ок цпіеѕѕ епріу([]), ӣо: еггог ("поіћіпд Ғоџцпа".) 
бӢе#р ок џп1іеѕѕ етріу (геза1®), до: оК (гези1) 


дер ок (геѕи1їі), до: { :оКк, геѕиіі } 
деЁр еггог (геаѕоп), ао: { :еггог, геаѕоп } 


Проанализируем функцию Ё1па таїсһіпд 1іпеѕ (). Если в качестве 
ее первого параметра указан кортеж с признаком :оКкК, то содержимое этого 
кортежа используется для поиска строк, совпадающих с заданным шаблоном 
раїіегп. Но если кортеж с признаком :оК не указан в качестве первого па- 
раметра данной функции, то выполняется ее второй вариант, который прос- 
то возвращает этот параметр. Таким образом, данная функция просто переда- 
ет ошибку дальше по конвейеру. Аналогичным образом действует и функция 
Египсабсе 13пез(). 

Мы можем поэкспериментировать с этим в консоли, как показано ниже. 
И, как видите, ошибка, возникающая в любом месте конвейера, сразу же стано- 
вится его значением. 


1ех> Сгер.Ғіпа а11 "/еёс/раѕѕма", -хг/ммм/ 

{:ок, [" мим:*:70:70:Мог1а М", " мимргоху:*:252:252:"] } 
іех> Сгер.Ё1пЧ а11 "/еіс/раѕѕма", ~г/мопраѓ+/ 

{:еггог, "посһіпд Ғоопа" } 

1ех> бгер.Ғіпа а11 "/еїс/Коаіа", ~г/иум/ 

{:еггог, :епоепі} 


Иначе обработка ошибок выполняется в самом конвейере 


Глядя на функции Ғіпа таёсһіпод 1Ііпеѕ () и ёгопсабе 1іпеѕ (), мож- 
но подумать, что бремя ответственности за обработку ошибок перенесено на 
преобразования. Так и есть. В таком языке, как ЕЇіхіг, где в вызовах функций 
применяется сопоставление с шаблоном, последствия подобного переноса смяг- 
чаются, но они все равно скверные. 

Было бы неплохо, если бы в языке ЕЇіхіг была внедрена такая разновидность 
конвейерного оператора | >, которому было бы известно, как обращаться с кор- 
тежами :оК/:еггок, чтобы сократить выполнение, когда возникает ошибка”. 


7 На самом деле такой оператор можно внедрить в Е]іхіг, используя его макросредства. 
Примером тому служит библиотека Мопа4 в шестнадцатеричной форме. Для этой цели 
можно также воспользоваться конструкцией м1 ЕВ языка ЕЙхи, но тогда потеряет всякий 
смысл программирование преобразований, выполняемых с помощью конвейеров. 
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Но, к сожалению, ничего подобного нельзя сделать в Е]іхіг, причем так, чтобы это 
было применимо и в ряде других языков. 

Дело в том, что когда возникает ошибка, было бы нежелательно выполнять код 
дальше по конвейеру, где совсем не обязательно знать о возникшей ошибке. Это 
означает, что выполнение некоторых функций в конвейере придется отложить до 
тех пор, пока не станет известно, что предыдущие стадии конвейерного процесса 
завершились удачно. И для этого вызовы функций придется заменить значени- 
ями функций, которые могут быть вызваны позднее. Ниже приведен один из 
примеров реализации такого подхода к обработке ошибок в конвейере. 


Ғопсііоп-ріре1іпез/ападгатѕ/1ір/дгер1.ех 
деЕмо4о1е Сгер1 ао 


её апа іһеп ({ :ок, уа1ае }, Еапс), до: Еапс. (уа1ае) 
дДе# апа_{Пеп (апуёһіпд е1ѕе, _Еипс), до: апуёһіпд е1ѕе 


Чеё Ғіпа а11 (Ғі1е пате, раёёегп) ао 
ҒіЈе.геаа (Ғі1е папе) 
|> апа їһеп (&#Ғіла таєсһіпа 11іпеѕ (&1, раїбегп)) 
|> апа іһеп (&їгопсаёе 11пе$ (&1)) 

епа 


бе#р Ғіпа тасһіпд Ііпеѕ (сопіепі, раіёегп) до 
сопіепі 
|> ЅЕгіпа. ѕр1іё (~р/\п/) 
|> Епим. #1 Јбег (&5ігіпа.таёсћ? (61, раёёегп)) 
|> ок ип1еѕѕ епріу () 


епа 
аер їігипсаїе 1іпеѕ (1іпеѕ) ао 
Ііпеѕ 
|> Епам.тмар (&5&г1па.$11се (&1, 0, 20)) 
[> ок () 
епа 
аеёЁр ок опіеѕѕ епрёу ([]), до: еггог ("поёһіпд Ғоцпа") 
беёр ок оп1Іеѕѕ епріу (геѕиіє), до: ок (геѕи1ї) 
дӢе#р оК (геѕиії), ао: { :оКк, геѕи1і } 
дӢеЁр еггог (геаѕоп), о: { :еггог, геаѕоп } 
епа 


Функция апа Пеп () служит примером функции связывания. Она принимает 
значение, заключенное в некоторую оболочку, а затем применяет к нему заданную 
функцию, возвращая новое значение, заключенное в оболочку. Чтобы восполь- 
зоваться функцией апа &һерг () в конвейере, потребуется дополнительная рас- 
становка знаков препинания, поскольку в языке Е]іхіг требуется явно указывать 
преобразование вызовов функций в значения функций, хотя эти дополнительные 
усилия возмещаются тем, что функции преобразования упрощаются. В частности, 
каждая из них принимает значение (и любые дополнительные параметры) и воз- 
вращает кортеж { : оК, новое_значение} или { :еггог, причина}. 
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ПРЕОБРАЗОВАНИЯ ПРЕОБРАЗУЮТ ПРОГРАММИРОВАНИЕ 


Осмысление кода как последовательности (вложенных) преобразований мо- 
жет стать освободительным подходом к программированию. Чтобы привыкнуть 
к этому, потребуется время, но как только вы выработаете в себе такую привыч- 
ку, то обнаружите, что ваш код станет более ясным, функции — более краткими, 
а проекты — более ровными. Попробуйте! 


Другие разделы, связанные с данной темой 


® Тема 8. Сущность качественного проектирования, глава 2 “Прагматичный 
подход”. 
ә Тема 17. Игры в скорлупки, глава 3 “Основные инструментальные сред- 
» 
ства”. 


® Тема 26. Как сбалансировать ресурсы, глава 4 “Прагматичная паранойя”. 
ѕ Тема 28. Развязывание. 


г Тема 35. Акторы и процессы, глава 6 “Параллельность”. 


Упражнения 


21. Можете ли вы выразить перечисленные ниже требования в виде преобразо- 
вания верхнего уровня? Определите для каждого из них входные и выход- 
ные данные. 


1) Налоги на поставку и с продаж добавляются в заказ. 
2) Приложение загружает конфигурацию из именованного файла. 


3) Пользователь входит в веб-приложение, регистрируясь в нем. 


22. Допустим, вы выяснили потребность проверить на достоверность и преоб- 
разовать символьную строку из поля ввода в целое число, находящееся в 
пределах от 18 до 150. В общих чертах такое преобразование описывается 
следующим образом: 

Е1е1А сопёепіѕ аз з6г1па 
ә [уа1ііааёе & сопуег{] 
Э {:оК, уа1ае} | {:егког, геаѕоп} 
Напишите код, реализующий отдельные преобразования, включающие про- 
верку на достоверность и преобразование. 
23. Ранее во врезке “Отсутствие конвейеров в языке Х” был приведен следую- 


щий фрагмент кода: 


сопзЕ сопіепі = Е11е.геаа (ЁЕ11е пате); 
сопѕЁ 1іпеѕ Ғіпа таёсһіпо 1іпеѕ (сопфепе, раїёегп) 
сопѕЕ геѕи1і ёгопсаёе 1іпеѕ (11пе$) 
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Многие разработчики пишут объектно-ориентированный код, составляя 
в цепочку вызовы методов. Они могли бы поддаться искушению написать 
приведенный выше фрагмент кода так, как показано ниже. 

сопзё геѕиії = сопіепі оЁ(Ё11е папе) 


.Ғіпа тасһіпа 11пе$ (рае Еегп) 
.Египсаее 11пе$ () 


Чем отличаются оба эти фрагмента кода? Какой из них, на ваш взгляд, явля- 
ется более предпочтительным? 


эч ФМ АА ора аат НА АУА ад УУМ А ЧАТЬ О 4 теат А И О НЯ 


НАЛОГ НА НАСЛЕДОВАНИЕ 


“Вам захотелось бананов, но в итоге вы получили 
гориллу, держащую банан, и целые джунгли”. 


Джо Армстронг!" 


Программируете ли вы на объектно-ориентированном языке и пользуетесь 
ли вы наследованием? Если так, то остановитесь! Ведь это, вероятнее всего, сов- 
сем не то, что вам требуется. В этом разделе поясняются причины. 


НЕМНОГО ПРЕДЫСТОРИИ 


Наследование впервые появилось в языке За 67 в 1969 году. Это было 
изящное решение задачи упорядочения нескольких типов событий в одном и 
том же списке. В подходе к наследованию, принятом в языке Ѕітија, принялись 
так называемые префиксные классы. Это давало возможность написать код, ана- 
логичный приведенному ниже. 


11пК СІАЅЅ саг; 
.. реализация автомобиля 
1іпк СЬА$З$ рісус1е; 
реализация велосипеда 


В данном коде 1іпк обозначает префиксный класс, внедряющий функцио- 
нальные возможности связанных списков. Это позволяет ввести автомобили и 
велосипеды в список транспортных средств, ожидающих, например, зеленого 
света дорожного светофора. В современной терминологии 1іпк обозначает ро- 
дительский класс. 

Мысленная модель, применявшаяся программирующими на Ѕітиа, состояла 
в том, что данным экземпляра и реализации класса 1іпк предшествовала реа- 
лизация классов саг и рісусі1е, а часть 11пК этой модели рассматривалась в 
основном как контейнер для хранения автомобилей и велосипедов. Тем самым 


10 ое Агтѕітопр — создатель языка Епапр. — Примеч. пер. 
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программирующие на Ѕітиа получали в свое распоряжение такую форму по- 
лиморфизма, в которой автомобили и велосипеды реализовывали интерфейс 
11п к, поскольку и те и другие содержали код 1іпк. 

Вслед за Ѕ5ітиа последовал язык $таШаК. Алан Кей, один из создателей 
ЗтаШа, отвечает на портале вопросов и ответов Оиоға за 2019 год!! на вопрос, 
почему в этом языке имеется наследование, следующим образом: 


“Когда я разработал язык ЗтаШаК-72 (а это было сделано шутки ради 
по зрелом размышлении о ЗтаШаК-71), я подумал, что было бы забавно 
воспользоваться [45р-подобной динамикой для экспериментирования с 
“дифференциальным программированием”. (Имеются в виду различные 
способы осуществить нечто подобное методом исключения.)” 


Это, в сущности, означает наследование исключительно для поведения. 

Обе эти разновидности наследования, у которых было очень много обще- 
го, постепенно развивались в течение последующих десятилетий. Принятый в 
Зипч]а подход, который предполагал в наследовании способ объединения типов 
данных, был продолжен в таких языках, как С++ и ]ауа. А направление, взятое в 
Зта[каЖ, где наследование считалось динамической организацией видов пове- 
дения, нашло свое продолжение в таких языках, как КаБу и ЈауаЅсгірі. 

С тех пор выросло целое поколение разработчиков объектно-ориентирован- 
ных приложений, которые пользуются наследованием по одной из двух причин: 
они не любят набирать код на клавиатуре или же им нравятся типы данных. 
Те, кто не любит набирать код на клавиатуре, берегут свои пальчики, исполь- 
зуя наследование для внедрения общих функциональных возможностей из ба- 
зового класса в порожденные классы. Например, подклассы Оѕег и РгоЧасе 
являются производными от класса АсііуеКесога: :Вазе. А те, кому нравятся 
типы данных, пользуются наследованием для того, чтобы выразить отношение 
между классами. Например, класс Саг реализует автомобиль как разновидность 
транспортного средства, реализуемого в классе Уер1с1е. Но, к сожалению, при- 
менение обеих упоминаемых здесь разновидностей наследования вызывает оп- 
ределенные трудности. 


ТРУДНОСТИ ПРИМЕНЕНИЯ НАСЛЕДОВАНИЯ ДЛЯ 
СОВМЕСТНОГО ИСПОЛЬЗОВАНИЯ КОДА 


Наследование означает связывание. При этом связывается не только порож- 
денный класс с родительским, но и родительский класс со своим родителем и 
т.д. Но исходный код, в котором применяется порожденный класс, связывается 
также со всеми своими предками. Ниже приведен характерный тому пример. 


П См. по адресу ВЕЕрз: / /мим . ааога . сом/Мһаё-аоеѕ-А1ап-Кау-іҺіпк-арооі- 


іпһегіёапсе-іп-орјесі-огіепіеа-ргодгаттіпа. 
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с1азз “Уеһісіе 
АеЁ іпіііа1іхғе 


@зрееа = 0 
епа 
её ѕіор 
@зрееа = 0 
епа 


её поуе аї (ѕрееа) 
@зрееа = ѕрееа 
епа 
епа 


с1азз Саг < Уеһісі1е 
дДе#Ғ іпғо 
"Т'м саг агіуіпд аё #{@ѕрееа} " 
епа 
епа 


# код верхнего уровня 
пу гіде = Саг.пем 
пу гіде.тоуе аї (30) 


Когда на верхнем уровне делается вызов пу саг.тоуе аї (), вызывается 
метод из класса Уеһіс1е, являющегося родительским для класса Саг. Теперь, 
когда разработчик, отвечающий за класс Уеһіс1е, вносит изменения в АРІ, ме- 
тод тоуе а+ () превращается в метод ѕеї уе1осіЇу (), а переменная экземп- 
ляра @ѕрееа — в переменную @уе1осіїу. 

Следует ожидать, что изменения в АРІ нарушат поведение клиентов класса 
Уећіс1е. Но этого не произойдет на верхнем уровне — по крайней мере, что 
касается применения в нем класса Саг. Ведь то, что делается в классе Саг сточ- 
ки зрения реализации, не касается кода верхнего уровня, хотя его функциони- 
рование все же нарушается. Аналогично имя переменной экземпляра относит- 
ся исключительно к подробностям внутренней реализации, но когда вносятся 
изменения в класс Уеһіс1е, негласно нарушается и функционирование класса 
Саг. И все это объясняется слишком тесным связыванием. 


Трудности применения наследования для построения типов данных 


Некоторые разработчики усматривают в наследовании способ определения 
новых типов данных. Их излюбленная проектная диаграмма показывает иерар- 
хии классов. Они рассматривают решаемые задачи так, как викторианские бла- 
городные ученые рассматривали в свое время природу как нечто, разделяемое 
на категории. 


Са! Всусе 
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Но, к сожалению, такие диаграммы вскоре, по мере ввода новых уровней 
наследования с целью выразить в мельчайших подробностях отличия между 
классами, вырастают до чудовищных размеров на всю стену. Такое усложнение 
способно сделать приложение более хрупким, как только вносимые в него изме- 
нения станут распространяться вверх и вниз по уровням наследования. 


Еще хуже дело обстоит с множественным наследованием. В частности, авто- 
мобиль, представленный в классе Саг, может быть разновидностью не только 
транспортного средства, представленного в классе Уећіс1е, но и активом, за- 
страхованной или закладываемой под ссуду частной собственностью, представ- 
ленными классами Аззеф, ТпзагеаТфеп и ІоапсСо11аіега1 соответственно. 
Для правильного моделирования такой иерархии классов потребуется множест- 
венное наследование. 

В 1990-е годы множественное наследование получило в языке С++ неудачное 
название в силу некоторой сомнительно разрешающей противоречия семанти- 
ки. В результате во многих современных объектно-ориентированных языках 
оно не поддерживается. Это означает, что вам не удастся точно смоделировать 
предметную область своего приложения, даже если вас вполне удовлетворяют 
сложные деревья типов данных. 


Не платите налог на наследование 


ЛУЧШИЕ АЛЬТЕРНАТИВЫ 


Рассмотрим три следующие методики программирования, которые обознача- 
ют, что вы не должны больше пользоваться наследованием. 


® Интерфейсы и протоколы. 
ә Делегирование. 


ә Миксины и свойства. 
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Интерфейсы и протоколы 


В большинстве объектно-ориентированных языков можно указать, что в 
классе реализуется один или несколько видов поведения. Например, в классе 
Саг реализуются виды поведения ргіуар1е и ГосафаЬ1е. Синтаксис, приме- 
няемый для этой цели, отличается в разных языках. Так, в языке Јауа он может 
выглядеть следующим образом: 


РУЬ11с с1азѕ Саг ир1етепез Пг1\уар1е, Іосаѓіарі1е { 
// Код для класса Саг. Этот код должен включать 
// в себя функциональные возможности обоих 
// интерфейсов Ог1уаю1е и Іосаїаріе 


} 


"”гіуар1е и Госаф аб1е называются в языке Јауа интерфейсами, а в других 
языках программирования — протоколами, а в некоторых — свойствами (їгаїѕ) 
(хотя термином “свойство” мы будем в дальнейшем называть нечто иное). 

Интерфейсы объявляются, например, так: 


рочЬ1іс іпёегҒасе Ггіуаріе { 
ЧочЬ1е сдеїіѕрееа () ; 
уоіа ѕіор (); 


} 


рчЬ1іс іпбегѓасе Іосаѓар1е () { 
СоогдӢіпаїе деїІоса+іоп (); 
Боо1еап 1осаїіопіѕУҮа1іа(); 

} 


В приведенных выше объявлениях не программируется никаких действий, а 
просто извещается, что в любом классе, реализующем интерфейс ргіхарі1е, обя- 
заны быть реализованы методы деї5рееа () и ѕіор (), ав классе, реализующем 
интерфейс Іосабсар1е, — методы деї1Іосаѓіоп () и Іосаїіопіѕуа1іа (). 
Это означает, что предыдущее определение класса Саг окажется действитель- 
ным лишь в том случае, если в него будут включены эти четыре метода. 

Сильной стороной интерфейсов и протоколов является возможность поль- 
зоваться ими как типами данных, причем любой класс, реализующий соответс- 
твующий интерфейс, будет совместим с его типом. Так, если оба класса Саги 
РҺопе реализуют интерфейс ГгосафаЪ1е, то их объекты можно размещать в 
списке элементов, определяемых по местоположению, как показано ниже. 

Ііѕі<Іосаёар1е> 1$етз = пем Аггау1іѕі<> (); 

ісетѕ.ааа (пем Саг(...)); 

іёетѕ .ааа (пем Рһопе (...)); 

ісетѕ.ааа (пем Саг (...)); 


р 


В таком случае можно обработать данный список, зная наверняка, что у каж- 
дого его элемента имеются методы деї1Іосаііоп () и ІосаёіопІѕУа1іа(): 
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уоіа ргіпіІосаііоп (Іосаїіар1іе іёетм) { 
1Е (1сетм.1осаёіопІѕҮа1іа() { 
рг1п® (ісетм.сдеі1осаїіоп () .аѕѕіёгіпа ()); 


} 


У ча 


іёетѕ . ЁогЕасћ (ргіпёІосаїіоп); 


Выражать полиморфизм предпочтительнее 
с помощью интерфейсов 


Интерфейсы и протоколы обеспечивают полиморфизм без наследования. 


Делегирование 


Наследование побуждает разработчиков создавать классы, у объектов ко- 
торых имеется большое количество методов. Так, если в родительском классе 
имеется 20 методов, а в его подклассе требуется воспользоваться лишь двумя из 
них, то в его объектах все равно будут доступны для вызова 18 остальных мето- 
дов. Можно сказать, что такой класс потерял контроль над своим интерфейсом, 
и это типичное затруднение. Так, многие каркасы хранения и пользовательского 
интерфейса требуют, чтобы компоненты приложения осуществляли наследова- 
ние подкласса от предоставляемого каркасом базового класса: 


с1аѕѕ Ассоцпі < РегѕізѕіепсеВаѕеСіаѕѕ 
епа 


Класс Ассоип® содержит теперь весь прикладной интерфейс АРІ класса 
РегѕіѕіепсеВаѕесС1аѕз. Рассмотрим в качестве альтернативы применение 
делегирования, как в приведенном ниже примере. 


с1азз Ассоцпі 
ег іпіёіа11іғе(. . .) 
@геро = Регѕіѕіег. Ғог (ѕе1#) 
епа 


дӢе# ѕауе 
@геро.ѕауе () 
епа 
епа 


Теперь из прикладного интерфейса АРІ ничто не доступно клиентам класса 
Ассоппе. Более того, мы не ограничены в своих действиях только АРІ применя- 
емого каркаса хранения и можем создать новый АРІ при надобности в таковом. 
Разумеется, мы могли бы сделать это и ранее, но всегда есть риск, что напи- 
санный нами интерфейс может быть обойден, а вместо него использован АРІ 
каркаса хранения. Теперь же мы полностью контролируем ситуацию. 
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Делегируйте полномочия службам: отношение СОДЕРЖИТ 
превосходит отношение ЯВЛЯЕТСЯ 


На самом деле можно пойти еще дальше. Зачем, например, классу Ассопп® 
знать, как сохраняться? Обязан ли он знать и соблюдать бизнес-правила ведения 
учетной записи: 


с1аз8 Ассоцпі 
# ничего, кроме сведений об учетной записи 
епа 


с1азз АссоппЕВесога 
# заключает в себе учетную запись с возможностями 
# извлечения и сохранения 

епа 


Теперь развязывание действительно достигнуто, хотя и не бесплатно. Для 
этого пришлось написать больше кода, часть которого, как правило, стереотип- 
ная. И вероятнее всего, что во всех классах записи потребуется, например, ме- 
тод Ғіпа (). Правда, для этой цели имеются миксины и свойства. 


Миксины, свойства, категории, расширения протоколов и прочее 


Те, кто работают в той же отрасли, где и все мы, любят присваивать разным 
понятиям замысловатые названия. И зачастую им присваиваются многие назва- 
ния. И чем их больше, тем лучше, не так ли? 

Именно так и происходит, когда мы рассматриваем понятие миксинов (тпіхіп). 
В их основу положена довольно простая идея: потребность в возможности рас- 
ширить классы и объекты новыми функциональными возможностями, не при- 
бегая к наследованию. С этой целью мы создаем ряд функций, присваиваем им 
имя, а затем определенным образом расширяем с их помощью класс или объект. 
И в этот момент создается новый класс или объект, сочетающий в себе функци- 
ональные возможности исходного класса и всех его миксинов. Зачастую такое 
расширение удается осуществить, даже если отсутствует доступ к исходному 
коду расширяемого класса. 

Реализация и название этих средств расширения отличается в разных языках. 
И хотя они называются здесь миксинами, их лучше рассматривать как средства, 
не зависящие от конкретного языка. И самое главное, что все их реализации 
обладают способностью объединять существующие и новые функциональные 
возможности. 

Вернемся снова к примеру класса Ассопп%Весока. В том виде, в каком мы 
оставили этот класс, ему нужно было знать как об учетных записях, так и о кар- 
касе хранения. Ему необходимо было также делегировать все методы на уровне 
хранения, которые требовалось открыть внешнему миру. 
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Миксины предоставляют альтернативу. Так, сначала мы могли бы написать 
миксин, реализующий, например, два или три стандартных метода поиска, а за- 
тем добавить его в класс АссоџпіКесога. По мере написания новых классов 
для сохраняемых элементов их также можно дополнять миксинами, как пока- 
зано ниже. 

піхіп СоптопЕ1паегз { 

ЧеЕ Ғіпа (іа) {... } 


АаеЕ Ғіпад11() {... } 
епа 


с1аѕз АссоцпіКесога ехіепаѕ Ваз1сВесога м1 В СоптопЕіпаегѕ 
с1азз ОгаегВесога ехфепаз ВаѕісКесога мііћ СоптопЕіпЯегѕ 


Можно пойти еще дальше. Всем разработчикам, например, известно, что биз- 
нес-объектам требуется код проверки достоверности, чтобы исключить проник- 
новение вредных данных в выполняемые вычисления. Но что именно имеется 
в виду под проверкой достоверности? Например, для учетной записи имеются, 
вероятно, самые разные уровни проверки достоверности, которые можно было 
бы применить в следующих целях: 


е совпадение хешированного пароля с тем, который ввел пользователь; 


ә проверка правильности данных, введенных пользователем в форму при 
создании учетной записи; 


® проверка правильности данных, введенных администратором, обновляю- 
щим сведения о пользователе; 


® проверка правильности данных, введенных в учетную запись другими 
компонентами системы; 


е проверка данных на согласованность перед сохранением. 


Типичный и, на наш взгляд, неидеальный подход состоит в том, чтобы увя- 
зать все проверки на достоверность в единый класс (бизнес-объект/объект со- 
храняемости), а затем ввести признаки, чтобы управлять выполнением отде- 
льных проверок в конкретных обстоятельствах. 

Лучший, на наш взгляд, способ состоит в применении миксинов для созда- 
ния специализированных классов, подходящих для конкретных случаев, как по- 
казано ниже, где в производные классы включаются проверки достоверности, 
общие для всех объектов учетных записей. 


с1аѕѕ АссоппЕГогСозбомег ехёепаѕ Ассоцпі 
м1ЕВ АссоцпіУа1іааёіопѕ, АссоцпіСиѕіотегУа1іааїіопѕ 


с1аззѕ АссоџпіҒогАатіп ехёепаѕ Ассоцпі 
м1 ЕР АссоцџпіУа1ідаііопѕ, АссоцџпіАатміпУуа1іааііопѕ 
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Клиентский вариант класса включает для себя также проверки достовернос- 
ти, пригодные для АРІ, взаимодействующих с клиентом, тогда как администра- 
тивный вариант класса, вероятно, должен содержать (возможно, менее ограни- 
чивающие) проверки достоверности учетных данных администратора. 

Теперь путем передачи экземпляров класса АссоипЕЕогСизеомег или 
АссоцпеЕогАам1п наш код автоматически обеспечивает правильное приме- 
нение проверок достоверности. 


Пользуйтесь миксинами для совместного использования 
функциональных возможностей 


НАСЛЕДОВАНИЕ РЕДКО ЯВЛЯЕТСЯ ОТВЕТОМ 

В этом разделе был сделан краткий анализ трех следующих альтернатив тра- 
диционному наследованию классов: 

$ интерфейсов и протоколов; 

® делегирования; 

® МИКСИНОВ И СВОЙСТВ. 

Каждая из этих методик может подойти вам лучше в тех или иных обстоя- 
тельствах, в зависимости от того, преследуете ли вы цель обмениваться инфор- 
мацией о типах данных, внедрять дополнительные функциональные возмож- 
ности или пользоваться общими методами. Как и везде в программировании, 
задача заключается в том, чтобы пользоваться той методикой, которая лучше 


всего выражает ваши намерения. 
И постарайтесь вместе с бананом не прихватить заодно целые джунгли. 


Другие разделы, связанные с данной темой 


• Тема 8. Сущность качественного проектирования, глава 2 “Прагматичный 
подход”. 
® Тема 10. Ортогональность, глава 2 “Прагматичный подход”. 


ә Тема 28. Развязывание. 


Задачи 


• В следующий раз, когда вам придется создавать подклассы, уделите вре- 
мя изучению разных альтернатив наследованию. Сможете ли вы достичь 
желаемой цели с помощью интерфейсов, делегирования и/или миксинов? 
Удастся ли вам подобным образом уменьшить степень связывания? 


ити: Ча РАО ЯША бит АА НАЧ се Ат. ето рр ИЛЬ ааа ГОСТ АЗ УДАЛЬ ОУ л М Пр тая аи поди. АУ М А018 ИА ИК ТАТ Оита речек Кое аА РА АИ ИКЕА Аа ати» 
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КонФфигуРИРОВАНИЕ 


“Уделяйте всем вашим вешам свои места, а каждой 
части ващего дела — свое время’. 


Бенджамин Франклин, автобиография 


Тринадцать добродетелей (Тћігіееп Уие$) 


Если прикладной код полагается на значения, которые могут измениться пос- 
ле запуска приложения, храните эти значения вне данного приложения. И если 
приложение выполняется в разных средах и потенциально работает для разных 
клиентов, также храните значения для разных сред и клиентов вне данного при- 
ложения. Подобным образом вы параметризируете свое приложение, исходный 
код которого приспосабливается к месту его выполнения. 


Параметризируйте свое приложение, используя внешнюю 
конфигурацию 


В данные конфигурации, вероятнее всего, придется включить разнообразные 
общие сведения. 


• Учетные данные для внешних служб (баз данных, сторонних АРІ и т.д.) 
• Уровни и места назначения протоколирования. 


ә Номера портов, ІР-адреса, имена вычислительных машин и кластеров, ис- 
пользуемые в приложении. 


® Параметры проверки достоверности, характерные для конкретной среды. 


® Внешне устанавливаемые параметры, например, ставки налогообложе- 
НИЯ. 


• Особенности форматирования для разных сайтов. 


е Лицензионные ключи. 


Словом, найдите все, что может измениться или быть выражено за предела- 
ми основного кода, и вынесите эту информацию в отдельную конфигурацион- 


ную “корзину”. 


СТАТИЧЕСКАЯ КОНФИГУРАЦИЯ 


Конфигурация многих каркасов и специализированных приложений хранится 
в обычных текстовых файлах или таблицах базы данных. Если конфигурацион- 
ные данные хранятся в обычном текстовом файле, то для этой цели, как правило, 
применяется один из доступных текстовых форматов. В настоящее время для 


Тема 32 • Конфигурирование 209 


этой цели чаще всего применяются такие текстовые форматы, как ҮАМІ и ]$ОМ. 
Иногда в приложениях, написанных на языках сценариев, применяются файлы 
исходного кода, специально предназначенные для хранения одной лишь конфи- 
гурации. Если подобная информация структурирована и, вероятно, будет изме- 
няться клиентом (например, ставки налога с продаж), ее лучше хранить в таб- 
лице базы данных. И, разумеется, вы вольны пользоваться обоими способами, 
разделяя конфигурационную информацию в соответствии с ее назначением. 

Независимо от формы хранения конфигурационной информации она вво- 
дится в приложение в виде структур данных — как правило, при запуске выпол- 
нения приложения. Эта структура данных обычно делается глобальной, чтобы 
упростить доступ к хранящимся в ней значениям из любой части прикладного 
кода. 

Однако мы не рекомендуем вам поступать таким образом. Вместо этого вы- 
несите всю конфигурационную информацию в отдельный (тонкий) АРІ. Этим 
вы развяжете свой код от подробностей представления его конфигурации. 


КонФИГУРАЦИЯ КАК СЛУЖБА 


Несмотря на распространенность статического конфигурирования, в настоя- 
щее время мы отдаем предпочтение другому подходу. Нам по-прежнему прихо- 
дится выносить конфигурационные данные за пределы приложения, но вместо 
того чтобы хранить их в текстовом файле или базе данных, мы предпочитаем 
получать их через АРІ отдельной службы. У такого подхода к конфигурирова- 
нию имеется целый ряд преимуществ, перечисленных ниже. 


з Многие приложения могут обмениваться конфигурационной информа- 
цией, при этом с помощью аутентификации можно ограничивать доступ, 
определяя, какую информацию может видеть каждое из них. 


• Изменения конфигурации могут выполняться глобально. 


• Конфигурационные данные можно сопровождать с использованием специ- 
ализированного пользовательского интерфейса. 


Ф Конфигурационные данные становятся динамическими. 


Последнее из перечисленных выше преимуществ, предполагающее динами- 
ческий характер конфигурационных данных, имеет решающее значение для 
перехода к приложениям с высокой степенью доступности. Необходимость 
остановки и перезапуска приложения для изменения единственного парамет- 
ра конфигурации безнадежно оторвана от современной действительности. При 
использовании службы конфигурирования компоненты приложения могут за- 
регистрироваться для получения уведомлений об обновлении используемых 
ими параметров, и тогда служба могла бы посылать им сообщения, содержащие 
новые значения — когда и если они изменятся. 
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Какую бы форму ни принимали конфигурационные данные, именно они оп- 
ределяют поведение приложения во время выполнения. Перестраивать код при- 
ложения, когда конфигурационные значения изменяются, нет необходимости. 


НЕ ПИШИТЕ МОРАЛЬНО УСТАРЕВШИЙ КОД 


В отсутствие внешней конфигурации прикладной код перестает быть на- 
столько приспосабливающимся и гибким, насколько он мог бы им быть. Плохо 
ли это? Если обратиться к примеру из природы, то можно заметить, что в ней 
вымирают те виды, которые не могут приспособиться к реальным условиям су- 
ществования. 

Так, птице дронту так и не удалось приспособиться к присутствию людей и 
домашнего скота в местах ее обитания на острове Маврикий, и поэтому этот 
вид быстро вымер". И это был первый задокументированный случай вымира- 
ния вида от рук человека. Поэтому не позволяйте своему проекту (или карьере) 


пойти по пути дронта!. 


Другие разделы, связанные с данной темой 


ѕ Тема 9. ОКУ — пороки дублирования, глава 2 “Прагматичный подход”. 


Тема 14. Предметно-ориентированные языки, глава 2 “Прагматичный под- 


» 


ход. 


Тема 16. Сила простого текста, глава 3 “Основные инструментальные 
средства”. 


Тема 28. Развязывание. 


12 И нисколько не улучшило положение то обстоятельство, что поселенцы забивали ду- 
бинками безмятежных (а по существу, глупых) птиц ради развлечения. 


Г Изображение дронта взято из серии ОрепСіірагі-Уесќогѕ, доступной на веб-сайте РіхаБбау 
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В первом издании данной книги мы предлагали пользоваться конфигура- 
цией вместо кода подобным же образом. Но мы, очевидно, должны были 
точнее давать свои рекомендации. Ведь любой совет можно довести до 
крайности или воспользоваться им несообразно. Поэтому ниже даются не- 
которые предостережения по данному поводу. 


Не переусердствуйте. Один из наших прежних клиентов решил, что бук- 
вально каждое поле в его приложении должно быть конфигурируемым. 
В итоге на внесения даже самых мелких изменений уходили целые недели, 
поскольку приходилось реализовывать как само поле, так и весь админис- 
тративный код для сохранения и редактирования его содержимого. А ведь 
в этом приложении насчитывалось до 40 тысяч переменных конфигурации, 
что превращало кодирование в сущий кошмар для разработчиков. 


Не принимайте решения относительно конфигурирования из лени. Если 
возникает реальная дискуссия о том, как должно действовать какое-то фун- 
кциональное средство и следует ли дать пользователю возможность выби- 
рать режим его работы, попробуйте реализовать один из его вариантов и 
получить отзывы о нем, чтобы выяснить, насколько верным оказалось дан- 
ное решение. 


7 
з 


ГЛАВА 6 


_ ЙАРА 


Пока мы все находимся на одной и той же странице, а не читаем главу па- 
раллельно, начнем с некоторых определений. Параллельность (сопсштепсу) оз- 
начает такое такое поведение двух или большего количества фрагментов кода, 
как будто они выполняются одновременно. А параллелизм (рагаПеНзт) озна- 
чает, что они действительно выполняются одновременно. Чтобы добиться па- 
раллельности, необходимо выполнять код в среде, способной переключать вы- 
полнение между разными частями данного кода. Зачастую параллельный режим 
работы реализуется с помощью таких средств, как нити (НЪег), потоки выполне- 
ния (®Фгеа4) и процессы (ргосеѕѕ). 

Для того чтобы добиться параллелизма, требуется оборудование, способное 
выполнять несколько операций одновременно. Это могут быть многоядерные 
процессоры, несколько процессоров на одном компьютере или несколько свя- 
занных между собой компьютеров. 


Все ПАРАЛЛЕЛЬНО 


Практически невозможно написать код системы приличных масштабов, не 
прибегая к параллельности. Аспекты используемой параллельности могут быть 
явно выраженными или скрытыми в библиотеке. Параллельность необходима 
тогда, когда приложение должно взаимодействовать с реальным миром, где со- 
бытия происходят асинхронно: пользователи взаимодействуют с приложением, 
извлекаются данные, вызываются внешние службы, и все это происходит одно- 
временно. Если заставить все это выполняться последовательно, чтобы события 
наступали поочередно, то такая система будет работать медленно и не позволит 
выгодно использовать истинный потенциал оборудования, на котором она ра- 
ботает. Поэтому в этой главе будут подробно рассмотрены понятия параллель- 
ности и параллелизма. 

Разработчики нередко рассуждают о связывании, возникающем между фраг- 
ментами кода. При этом они ссылаются на зависимости и выясняют, насколько 
они затрудняют внесение изменений в исходный код. Но ведь имеется и другая 
форма связывания. В частности, временное связывание возникает в том случае, 
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когда прикладной код накладывает ограничение на последовательность выпол- 
нения действий, требуемых для решения текущей задачи. Может ли, например, 
ваш код зависеть от того, что “тик” происходит раньше “так”? Если вы хотите 
сохранить его гибкость — он не должен демонстрировать такую зависимость. 
Следует ли вашему коду обращаться к нескольким серверным службам после- 
довательно, т.е. к одной за другой? Нет, не следует, если вы хотите сохранить 
своих клиентов. Поэтому в разделе “Разрывание временного связывания” будут 
рассмотрены способы выявления временного связывания подобного рода. 

Почему так трудно писать параллельный код? Объясняется это, в частности, 
тем, что мы учились программировать с использованием последовательных сис- 
тем. Применяемые нами языки обладают средствами, которые надежны, когда 
они используются последовательно, но становятся ненадежны, как только два 
события могут наступить одновременно. Одним из главных виновников тому 
служит общее, или совместно используемое состояние, которое означает не толь- 
ко глобальные переменные. Такое состояние возникает в любой момент време- 
ни, когда два или несколько фрагментов кода содержат ссылки на один и тот 
же фрагмент изменяемых данных. Но общее состояние является неверным со- 
стоянием. В соответствующем разделе описывается ряд приемов, позволяющих 
обойти общее состояние, хотя все они не вполне надежны и непогрешимы. 

Если все сказанное выше опечалило вас, не отчаивайтесь! Ведь имеются спо- 
собы построения параллельных приложений и получше. К их числу относится 
применение модели акторов, где независимые процессы обмениваются данными 
по каналам, используя вполне определенную простую семантику. Теория и прак- 
тика такого подхода рассматривается в разделе “Акторы и процессы”. 

И в завершение этой главы будут рассмотрены классные доски, т.е. системы, 
действующие как комбинация хранилища объектов и интеллектуального бро- 
кера “издатель-подписчик” В своей исходной форме они так и не нашли широ- 
кого распространения, но в настоящее время наблюдается постепенно растущее 
количество реализаций на промежуточном уровне программного обеспечения с 
семантикой, похожей на классные доски. При правильном использовании такие 
системы обеспечивают серьезную степень развязывания. 

Когда-то параллельно выполняющийся код считался экзотикой. Сегодня же 
он востребован, как никогда ранее. 


РАЗРЫВАНИЕ ВРЕМЕННОГО СВЯЗЫВАНИЯ 


В связи с темой этого раздела невольно возникает вопрос: “А что такое вре- 
менное связывание?” Это связывание, связанное со временем (простите за ка- 
ламбур). 

Время — очень часто игнорируемый аспект в архитектурах программного 
обеспечения. Единственным временем, которое заботит разработчиков, явля- 
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ется срок выполнения работ по графику, т.е. время, оставшееся до выпуска. Но 
здесь речь идет не о самом времени, а о его роли в качестве элемента проекти- 
рования самого программного обеспечения. Для нас важны следующие аспекты 
времени: параллельность (события могут происходить одновременно) и упоря- 
дочение (относительное расположение событий во времени). 

Обычно мы подходим к программированию, не принимая во внимание ни 
один из упомянутых выше аспектов. Когда разработчики приступают к проек- 
тированию архитектуры или написанию программы, весь этот процесс проис- 
ходит в линейном порядке. Ведь большинство людей мыслят именно в таком 
порядке: сделать сначала это, а затем то. Такой порядок мышления приводит к 
временному связыванию, т.е. к такому, которое возникает во времени. Так, метод 
А должен всегда вызываться прежде метода В; одновременно может быть со- 
ставлен лишь один отчет; щелкнув на экранной кнопке, нужно подождать до тех 
пор, пока не будет перерисовано выводимое на экран графическое изображение; 
“тик” хронологически должен предшествовать “таку”. 

Такой подход негибок и не очень реалистичен. 

Необходимо допустить параллельность и подумать о развязывании в любой 
момент времени или упорядочить зависимости. Поступая подобным образом, 
можно добиться нужной гибкости и снизить любые временные зависимости на 
многих стадиях разработки: анализа последовательности выполняемых дейс- 
твий, построения архитектуры, проектирования и развертывания. В итоге по- 
лучаются системы, которые легче осмысливать и которые потенциально быстрее 
реагируют и более надежны. 


В поискАХ ПАРАЛЛЕЛЬНОСТИ 


Во многих проектах требуется моделировать и анализировать последова- 
тельность выполняемых действий в приложении как часть проектирования. 
При этом нам хотелось бы выяснить, что может произойти одновременно и 
что должно произойти в строгом порядке. С этой целью можно, например, за- 
фиксировать последовательность выполняемых действий, используя такое обоз- 
начение, как диаграмма действий!. 


Анализируйте последовательность выполняемых действий 
с целью повышения параллельности 


: Несмотря на то что язык ОМГ постепенно пришел в упадок, многие из его отдельных 
диаграмм по-прежнему существуют в той или иной форме, включая и очень полезную 
диаграмму действий. Подробнее о типах диаграмм ОМІ см. в книге ОМІ Рі5і1е4: А Вгіеў 
Сиіде Ю Ше Эвпаата ОБјесі Модеііпе Гапзиаке [Еом04]. 
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Диаграмма действий состоит из ряда действий, отображаемых прямоугольни- 
ками со скругленными углами. Стрелка, проведенная от одного действия, ведет 
либо к другому действию (которое может быть начато, как только завершится 
первое действие), либо же к толстой линии, называемой чертой синхронизации. 
И как только завершатся все действия, приводящие к черте синхронизации, пос- 
троение диаграммы можно продолжить, проводя стрелки от этой черты дальше. 
Действие без ведущих к нему стрелок может быть начато в любой момент. 

С помощью диаграмм действий можно довести параллелизм до максимума, 
выявляя те действия, которые могут быть выполнены параллельно, но таким 
образом не выполняются. Допустим, разрабатывается программное обеспече- 
ние роботизированного аппарата для приготовления коктейлей “пинаколада” 
из светлого рома, кокосового молока и ананасового сока. С этой целью разра- 
ботчики получили следующее поэтапное описание процедуры приготовления 
таких коктейлей. 


1. Открыть блендер 7. Закрыть блендер 

2. Открыть смесь “пинаколада” 8. Взбалтывать в течение 1 минуты 
3. Поместить смесь в блендер 9. Открыть блендер 

4. Отмерить полстакана светлого рома 10. Взять высокие бокалы 

5. Налить ром 11. Взять розовые зонтики 

6. Добавить 2 чашки льда 12. Подать 


Но бармен потеряет свою работу, если последует этой процедуре поэтапно. 
Несмотря на то что действия по приготовлению коктейля описаны последова- 
тельно, многие из них могут быть выполнены параллельно. Воспользуемся при- 
веденной ниже диаграммой действий, чтобы зафиксировать и обдумать потен- 
циальную параллельность. 

Выявление реально существующих зависимостей может стать полным откро- 
вением. В данном случае все задачи верхнего уровня (1, 2, 4, 10 и 11) могут быть 
(одновременно) выполнены в первую очередь, а во вторую очередь — задачи 3, 5 
и 6 (также одновременно). Если бы вы принимали участие в конкурсе на лучше- 
го составителя коктейля “пинаколада’, подобные оптимизации данной процеду- 
ры могли бы оказать вам существенную помощь в достижении желанной цели. 


Возможности для ДОСТИЖЕНИЯ ПАРАЛЛЕЛЬНОСТИ 


Диаграммы действий показывают потенциальные участки параллельности, 
но ничего не говорят о том, стоит ли использовать параллельность. Так, в рас- 
смотренном выше примере приготовления “пинаколады” бармену потребова- 
лось бы пять рук, чтобы выполнить все потенциально первоначальные задачи 
одновременно. 
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2. 1. Открыть 4. 
ткрыть смесь тмерить 
Открыть смес блендер Отмерить ром 


3. 6. 5. 
Поместить Добавить Налить ром 
смесь в блендер две чашки льда 


7. Закрыть 
блендер 
Смешать 

9. Открыть 
блендер 


Взять 
розовые зонтики 


10. Взять 
высокие бокалы 


12 


’ Подать 


Именно здесь и наступает стадия проектирования. Глядя на упомянутые 
выше действия, мы осознаем, что на действие 8 (работа блендера) потребуется 
одна минута. В течение этого промежутка времени бармен может взять высокие 
бокалы и розовые зонтики (действия 10 и 11), и, возможно, у него еще останется 
время, чтобы обслужить другого клиента. 

Именно такие моменты мы и ищем, когда выполняем проектирование с уче- 
том параллельности. При этом мы надеемся найти действия, отнимающие вре- 
мя, но не время для выполнения нашего кода. Запрос базы данных, доступ к 
внешней службе, ожидание ввода пользователем данных — все эти действия, 
как правило, приостанавливают выполнение программы до тех пор, пока они не 
завершатся. И все они открывают возможности сделать программу более произ- 
водительной, не заставляя процессор простаивать в холостую. 


Возможности ДЛЯ ДОСТИЖЕНИЯ ПАРАЛЛЕЛИЗМА 


Напомним главное отличие: параллельность (сопсштепсу) — это програм- 
мный механизм, а параллелизм (рагаејіѕт) — предмет заботы оборудования. 
Если в нашем распоряжении имеется несколько процессоров, доступных ло- 
кально или дистанционно, то, распределив работу между ними, мы можем со- 
кратить общее время ее выполнения. 
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— УСКОРЕННОЕ ФОРМАТИРОВАНИЕ  _ 


Эта книга написана простым текстом. Чтобы составить ее версию для печа- 
ти, электронной книги или иных целей, ее текст был пропущен через кон- 
вейер процессоров. Одни из них находили конкретные конструкции (ссыл- 
ки на литературу, статьи предметного указателя, специальную разметку для 
советов и т.д.), а другие оперировали рукописью как документом в целом. 


Многие процессоры в конвейере должны получать доступ к внешней ин- 
формации (читать и записывать текст в файлы, обращаться к внешним про- 
граммам по конвейеру). Вся эта относительно медленно выполняемая рабо- 
та дает нам возможность поставить себе на службу параллельность: факти- 
чески каждый этап конвейера выполняется параллельно, получая результа- 
ты работы предыдущего этапа и передавая другие результаты следующему 
этапу работы конвейера. 


Кроме того, на некоторых стадиях процесса требуется относительно интен- 
сивное употребление процессоров. К их числу относится преобразование 
математических формул. По разным историческим причинам для преобра- 
зования каждого уравнения может потребоваться до 500 мс. Чтобы уско- 
рить дело, можно с выгодой воспользоваться параллелизмом. Каждая фор- 
мула не зависит от других формул, поэтому ее можно преобразовывать па- 
раллельно в отдельном процессе, собирая полученные результаты обратно 
в книгу, как только они становятся доступными. 


В итоге составление книги на компьютере с многоядерным процессором 
намного ускоряется. И, разумеется, по ходу дела выявили целый ряд оши- 
бок параллельности в составленном нами конвейере... 


В идеальном случае разделяемые подобным образом части работы являются 
независимыми, т.е. каждая из них может быть продолжена, ничего не ожидая 
от других. Типичный шаблон разделяет крупную часть работы на независимые 
фрагменты, которые обрабатываются параллельно, а затем полученные резуль- 
таты объединяются. 

Интересным практическим примером может служить принцип действия ком- 
пилятора в языке Ейхи. После запуска этот компилятор разделяет проект, ко- 
торый он строит, на модули, компилируя их параллельно. Иногда один модуль 
зависит от другого, и тогда компиляция приостанавливается до тех пор, пока 
результаты построения одного модуля не станут доступными для построения 
другого модуля. Завершение построения модуля верхнего уровня означает, что 
все его зависимости скомпилированы. В итоге процесс компиляции заметно ус- 
коряется благодаря тому, что задействованы все имеющиеся ядра процессора. 
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ВЫЯВИТЬ ВОЗМОЖНОСТИ ПРОЩЕ ВСЕГО 


Вернемся, однако, к приложениям. Мы выявили в них места, где можно из- 
влечь выгоду из параллельности и параллелизма. Теперь предстоит самое труд- 
ное: решить, как все это надежно реализовать. Данному вопросу и посвящена 
остальная часть этой главы. 


Другие разделы, связанные с данной темой 


® Тема 10. Ортогональность, глава 2 “Прагматичный подход”. 


Тема 26. Как сбалансировать ресурсы, глава 4 “Прагматичная паранойя”. 


® Тема 28. Развязывание, глава 5 “Гибкость или ломкость”, 


Тема 36. Классные доски. 


Задачи 


» Сколько задач вы решаете параллельно, собираясь утром на работу? Не 
могли бы вы выразить эту процедуру в виде диаграммы действий на языке 
ОМІ? Можете ли вы найти способ собраться на работу быстрее, увеличив 
степень параллельности своих действий? 


Теа А хо рее Ире 0и МО ДА Ри Де ин рии второе Ите ела из их 2 О О С ааа ы 


ОБЩЕЕ СОСТОЯНИЕ — НЕВЕРНОЕ СОСТОЯНИЕ 


Представьте себя за обедом в своем любимом ресторане. Покончив с основ- 
ным блюдом, вы спрашиваете официанта, остался ли еще яблочный пирог. Глядя 
через плечо, он замечает один кусок на прилавке-витрине и отвечает утверди- 
тельно. Вы делаете заказ и удовлетворенно вздыхаете. 

В это время на другой стороне ресторана еще один посетитель задает офици- 
анту тот же самый вопрос. Он также смотрит на прилавок-витрину, убеждается 
в наличии куска пирога, отвечает утвердительно, и тогда другой посетитель де- 
лает аналогичный заказ. В итоге один из посетителей ресторана остается разо- 
чарованным. 

Замените прилавок-витрину совместным банковским счетом, а обслужива- 
ющий персонал ресторана — кассовыми терминалами и представьте, что вы и 
ваш супруг или супруга решили одновременно купить новый телефон, но денег 
на счете у вас хватит лишь на один. В итоге кто-то (банк, магазин или вы) оста- 
нетесь весьма недовольны. 
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Все дело в совместно используемом общем состоянии. Каждый из официан- 
тов посмотрел на прилавок-витрину в ресторане, но не друг на друга. И каждый 
кассовый терминал проанализировал остаток на счете безотносительно к друго- 
му кассовому терминалу. 


НЕАТОМАРНЫЕ ОБНОВЛЕНИЯ 


Рассмотрим пример ситуации в ресторане. Ниже показано, как реализовать 
его непосредственно в коде. 


Прилавок-витрина 


р1е соџпі: 1 


іё аіѕр1ау саѕе.ріе соцпі > 0 1Е аіѕр1Іау саѕе.ріе сойпе > 0 
ргопіѕе ріе іо сиѕіотег () ргом1зе ріе іо сизбомег () 
аіѕр1Іау саѕе.ёаке ріе () аіѕр1ау саѕе. саке ріе () 


діуе ріе іо сизіотег () діуе ріе їо сизѕзіотег () 
епа епа 


Оба официанта действуют одновременно, а на практике — параллельно. Рас- 
смотрим код, реализующий их поведение: 
1Е аіѕр1Іау саѕе.ріе соопі > 0 
рготіѕе ріе іо сиѕіопег () 
аіѕрІау саѕе.іаке ріе () 
діуе ріе ёо сиѕіоптег () 
епа 


В этом коде первый официант получает текущий подсчет количества кусков 
пирога и обнаруживает, что он равен единице. И тогда он обещает пирог свое- 
му клиенту. Но в тот же самый момент действует и второй официант. Он также 
обнаруживает, что текущий подсчет количества кусков пирога равен единице, и 
обещает тот же самый пирог своему клиенту. В итоге один из двух официантов 
берет оставшийся кусок пирога, тогда как другой официант переходит в некото- 
рого рода состояние ошибки, что, вероятнее всего, вызовет немало извинений. 

Все дело не в том, что два процесса могут записывать данные в одну и ту 
же область памяти, а в том, что ни один из них не может гарантировать, что 
его представление о данной области памяти согласовано с другими. По су- 
ществу, когда код, реализующий поведение официанта, выполняет метод 
415р1ау саѕе.ріе соцпї (), он копирует значение, определяющее количес- 
тво кусков пирога, из объекта діѕр1ау саѕе в свою область памяти. Если же 
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это значение в объекте 415р1ау_сазе изменится, содержимое данной области 
памяти, которая используется для принятия решений, окажется неактуальным. 
Все это происходит потому, что извлечение и обновление подсчета кусков 
пирога не является атомарной операцией, поскольку базовое значение может 
измениться посредине данной операции. Так как же сделать ее атомарной? 


Семафоры и другие формы взаимного исключения 


Семафор — это просто ресурс, которым может одновременно владеть лишь 
кто-то один. Семафор можно создать, а затем воспользоваться им для управ- 
ления доступом к какому-нибудь другому ресурсу. В рассматриваемом здесь 
примере можно было бы создать семафор для управления доступом к прилавку 
с пирогом, приняв условие, что всякий, кому требуется обновить содержимое 
прилавка, может сделать это лишь в том случае, если он владеет данным сема- 
фором. 

Допустим, проблема пирога в ресторане решается с помощью такого сема- 
фора. С этой целью на прилавок-витрину поставили пластмассовую фигурку 
лепрекона?. Прежде чем подать пирог, официант должен взять в руку фигурку 
лепрекона. Как только он выполнит заказ (что означает доставку пирога на стол 
посетителя), он может возвратить фигурку лепрекона на место, где тот охраняет 
пирожные сокровища и готов содействовать следующему заказу. 

Теперь выясним, как реализовать такой семафор непосредственно в коде. По 
классической традиции операция захвата семафора называлась Р, а операция его 
освобождения — У?. Сейчас для этой цели употребляются такие термины, как 
блокировка и разблокировка, захват и освобождение и т.д. Так, в приведенном 
ниже коде предполагается, что семафор уже создан и хранится в переменной 
сазе зетарпоге. 


сазе ѕетарһоге.1оск () 


1Е аіѕр1ау саѕе.ріе соцпе > 0 
рготіѕе ріе Ко сиѕіотег () 
915р1ау саѕе.баке ріе () 
аіуе ріе їо сиѕіопег () 

епа 


саѕе ѕетарһоге.оп1оск () 


" Лепрекон — персонаж ирландского фольклора, волшебник, исполняющий желания и 
традиционно изображаемый в виде небольшого коренастого бородатого человечка. — 
Примеч. пер. 


? Названия операций Р и У являются производными от начальных букв двух голланд- 
ских слов, хотя по этому поводу все еще ведется полемика. Изобретатель данного метода, 
Эдсгер Дейкстра (Ейѕрег ГіјКѕїга), предложил два слова раѕѕегіпр (передать) и ргоіаау (по- 
пытаться понизить уровень) для названия операции Р и слово угйвауе (снять запрет) и, 
возможно, слово уегйосеп (повысить уровень) для названия операции У. 


222 Глава 6 = Параллельность 


Допустим, фрагменты кода, реализующие действия обоих официантов, вы- 
полняются одновременно. Они оба пытаются заблокировать семафор, но удает- 
ся это лишь одному из них. Тот код, который захватывает семафор, продолжа- 
ет выполняться как обычно, а другой код приостанавливает свое выполнение 
до тех пор, пока семафор не освободится (т.е. второй официант ожидает своей 
очереди выполнить заказ). Как только первый официант завершит выполнение 
своего заказа, он разблокирует семафор, и тогда второй официант продолжит 
свою работу. Теперь он видит наличие пирога на прилавке-витрине и приносит 
свои извинения посетителям, попросившим пирог. 

Такой подход к разрешению конфликтов при одновременном выполнении 
операций вызывает некоторые затруднения. И самое, вероятно, существенное 
из них состоит в том, что такой подход оказывается работоспособным лишь в 
том случае, если все, кто имеет доступ к прилавку-витрине, соглашаются на ус- 
ловие пользоваться семафором. Если кто-нибудь из них забудет о нем, т.е. если 
какой-то разработчик напишет код, не соблюдающий данное условие, то снова 
возникнет беспорядок. 


Придание ресурсам транзакционного характера 


Рассматриваемое здесь проектное решение оказывается неудачным потому, 
что ответственность за защиту доступа к прилавку с пирогом возлагается на 
тех, кто им пользуется. Изменим это решение таким образом, чтобы центра- 
лизовать управление доступом к прилавку с пирогом. Для этого нам придется 
внести в АРІ такие изменения, которые позволят официантам проверять под- 
счет количества кусков пирога и нарезать пирог в течение одного вызова, как 
показано ниже. 

ѕ1ісе = аіѕрІау сазе.дее р1е 1Ё ауаі1арі1е () 

1Е 51ісе 

діуе ріе іо сиѕіотег () 
епа 


Чтобы сделать приведенный выше код работоспособным, необходимо напи- 
сать приведенный ниже метод, частично выполняющий функции самого при- 
лавка. 


де? де ріе 1Е ауаі1арі1е () ННЯ 
1Е @51ісеѕ.ѕіле > 0 $ 
ирЧаее за1ез_Чаба (:ріе) ы 
геёогп @511сез. 301% # 
е1ѕе # неверный код! 
Ға1зе # 
епа $ 
епа НН 


Данный код наглядно показывает типичное заблуждение. 
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Несмотря на то что доступ к ресурсу перемещен в центральное место, объ- 
являемый метод все равно может быть вызван из нескольких одновременно вы- 
полняющихся потоков. Следовательно, он должен быть по-прежнему защищен 
семафором, как показано ниже. 


АеЕ де р1е_1Ё ауаі1ар1е () 
@сазе ѕетарһоге.1оск () 
12 @51ісеѕ.ѕізе > 0 

џрааёе ѕаіез Яаѓа (:ріе) 
геёсџгп @5$11се$. 5116 
е]зе 
Ға1зе 
епа 
@сазе_зетарпоге.ип1оск () 
епа 


Но даже этот код может оказаться неверным. Так, если в методе џрдаќе _ 
за1ез Чафа() будет возбуждено исключение, семафор так и не будет разбло- 
кирован, и весь последующий доступ к прилавку с пирогом зависнет на неопре- 
деленное время. Этот недостаток придется исправить следующим образом: 


4еЁЕ деф ріе ії ауаі1арі1е () 
@сазе ѕетарһоге.1оск () 


бгу | 


1Е @5$11сез.$17е > 0 
џраасе ѕа1езѕ Яаѓа (:ріе) 
геїогп #511сеѕ.5һіЁС 

еізе 
Ға1ѕе 

епа 

} 
епзиге { 
@саѕе ѕетарһоге.оп1оск () 


} 


епа 


Данная ошибка настолько типична, что во многих языках предоставляются 
отдельные библиотеки, устраняющие ее автоматически, как показано ниже. 


4еЕ сеї ріе ії? ауа11аЮ1е () 
@саѕе ѕетарһоге.ргоіесї () { 
12 @51ісеѕ.ѕіғе > 0 
ораабе ѕа1еѕ Яаќа (:ріе) 
гөёогп @511се5. 501 
е1 зе 
Ға1зе 
епа 
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МножесСТВЕННЫЕ ТРАНЗАКЦИИ РЕСУРСОВ 


В упомянутом выше ресторане только что установили мороженицу. Если по- 
сетитель закажет яблочный пирог с мороженым, официанту придется проверить 
наличие не только пирога, но и мороженого. С этой целью код, реализующий 
действия официанта, можно было бы изменить следующим образом: 


511се = 915р1ау сазе.дее ріе 1Ё ауа11аЪ1е () 
ѕсоор = Ёгееғег.деі ісе сгеам 1Ё ауа11ар1е () 


1Е $11се && ѕсоор 


члуе_ог4ег іо сиѕіоптег () 
епа 


Но так не годится. Что, если посетитель потребует кусок пирога, и когда 
официант попытается достать шарик мороженого, то его не окажется в нали- 
чии? В итоге он останется держать в руках кусок пирога, не зная, что с ним 
делать, поскольку посетителю следует принести яблочный пирог непременно с 
мороженым. И тот факт, что официант держит в руках пирог, означает, что его 
уже нет на прилавке, а следовательно, его не достанется какому-нибудь другому 
посетителю, из принципа не желающего есть яблочный пирог с мороженым. 

Это положение можно было бы исправить, введя в объект, представляющий 
прилавок с пирогом, метод, позволяющий возвратить кусок пирога. Чтобы не 
удерживать используемые ресурсы в том случае, если что-нибудь пойдет не так, 
как предполагалось, в данный метод следует ввести обработку исключений: 


ѕ1ісе = аіѕрІау сазе.дее ріе 1Е ауаі1ар1е () 


1Е 511Ссе 
Егу { 
ѕсоор = Ёгееғег.де ісе сгеат ії ауаі1ар1е () 
ЇЁ ѕсоор 
Егу { 
91уе_ог4аег іо сиѕіотег () 
} 
гезсие { 
Ғгееғег.діуе раск (ѕсоор) 
} 
епа 
} 
гезсое { 
аіѕр1Іау саѕе.діуе раск (ѕ51ісе) 
} 


епа 


Но и такое решение отнюдь не идеально. Теперь код выглядит весьма урод- 
ливо. Выяснить, что он действительно делает, не так-то просто, поскольку биз- 
нес-логика скрывается в нем за служебными операциями. 
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Ранее подобный недостаток был устранен перенесением кода, обращающе- 
гося с ресурсом, в сам ресурс. Но здесь задействованы два ресурса. Следует ли 
перенести код в реализацию прилавка с пирогом или мороженицы? Мы счита- 
ем, что не следует ни в одно из этих мест. Прагматичный подход подсказывает, 
что яблочный пирог с мороженым следует рассматривать как отдельный ресурс. 
Поэтому код лучше перенести в новый модуль, и если посетитель ресторана за- 
кажет такой десерт, то выполнить его заказ либо удастся, либо не удастся. 

Разумеется, в меню настоящего ресторана может быть немало составных 
блюд, подобных упомянутому выше, так что вряд ли стоит писать отдельный 
модуль для каждого из них. Вместо этого, вероятнее всего, придется сделать в 
каждом составном блюде из меню ссылки на его составляющие, а затем объ- 
явить обобщенный метод де тепи іёет (), выделяющий ресурс по каждой 
ссылке. 


ОБНОВЛЕНИЯ БЕЗ ТРАНЗАКЦИЙ 


Общей памяти как источнику осложнений, возникающих в связи с парал- 
лельностью, уделяется немало внимания, но на самом деле эти осложнения мо- 
гут возникнуть везде, где прикладной код разделяет общие изменяемые ресурсы: 
файлы, базы данных, внешние службы и т.д. Всякий раз, когда два или более 
фрагмента прикладного кода могут одновременно получить доступ к некоторо- 
му ресурсу, следует усматривать потенциальное осложнение. 

Иногда ресурс не вполне очевиден. Работая над настоящим изданием дан- 
ной книги, мы обновили набор инструментальных средств, чтобы выполнить 
больше работы в параллельном режиме с помощью потоков выполнения. Это 
привело к тому, что сборка завершалась неудачно, но странными способами и 
в произвольных местах. Общим для всех ошибок оказалось то, что файлы или 
каталоги не удавалось найти, несмотря на то, что они находились именно там, 
где им и следовало быть. 

Мы проследили эту тенденцию до двух мест в своем коде, где временно изме- 
нялся текущий каталог. В нераспараллеленной версии кода обратное восстанов- 
ление каталога было вполне приемлемым, но в распараллеленной версии ката- 
лог изменялся в одном потоке выполнения, а затем начинал выполняться другой 
поток в том же самом каталоге. В этом потоке предполагалось выполнение в 
первоначальном каталоге, но этого не происходило, поскольку текущий каталог 
совместно использовался в обоих потоках выполнения. 

Характер подобной ошибки подсказывает еще один совет: 


Случайные отказы часто вызваны осложнениями, 
возникающими в связи с параллельностью 
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ДРУГИЕ ВИДЫ ИСКЛЮЧИТЕЛЬНОГО ДОСТУПА 


В большинстве языков программирования имеются библиотеки, поддержи- 
вающие некоторые виды исключительного доступа к общим ресурсам. Они мо- 
гут называться мьютексами“, мониторами или семафорами. Все эти средства 
поддержки параллельности реализуются в виде библиотек. 

Но в некоторые языки поддержка параллельности встроена непосредственно. 
Например, в языке Киѕї соблюдается принцип владения данными, в соответствии 
с которым лишь одна переменная или параметр может одновременно хранить 
ссылку на любой конкретный фрагмент изменяемых данных. 

Можно, конечно, утверждать, что реализовать параллельность в языках фун- 
кционального программирования проще, поскольку им присуще делать все дан- 
ные неизменяемыми. Но и в них возникают те же самые трудности, поскольку 
в какой-то момент им все равно приходится вступать в реальный изменчивый 
мир. 


Доктор, МНЕ БОЛЬНО... 


Если вы не вынесете для себя ничего полезного из этого раздела, примите 
во внимание хотя бы следующее: добиться параллельности в среде с общими 
ресурсами нелегко, и попытки сделать это самостоятельно сопряжены с серьез- 
ными трудностями. 

Именно поэтому мы решили завершить этот раздел старой шуткой: 


— Доктор, мне больно, когда я делаю вот так... 
— Ну так не делайте вот так. 
В двух последующих разделах рассматриваются альтернативные способы без- 
болезненного извлечения выгод из параллельности. 
Другие разделы, связанные с данной темой 
ә Тема 10. Ортогональность, глава 2 “Прагматичный подход”. 
ә Тема 28. Развязывание, глава 5 “Гибкость или ломкость”. 


ә Тема 38. Программирование по совпадению, глава 7 “По ходу кодирования”. 


И В НК 


От анг, тиша! ехсияюп — взаимное исключение. — Примеч. пер. 
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Акторы И ПРОЦЕССЫ 


“Без писателей никто не напишет истории, 
а без актеров никто не воплотит истории в жизнь”. 


Анджи-Мари Дельсанте? 


Акторы и процессы предоставляют интересные способы реализации парал- 
лельности, избавляя от бремени синхронизации доступа к общей памяти. Но, 
прежде чем перейти к их рассмотрению, необходимо определить их назначение. 
И хотя это определение покажется вам несколько академичным, примите его 
безбоязненно, а мы подробно растолкуем его вскоре. 


• Актор (асіог) — это независимый виртуальный процессор с собственным 
локальным (или закрытым) состоянием. У каждого актора имеется свой 
почтовый ящик. Как только в этом ящике появится сообщение, простаи- 
вающий в ожидании актор активизируется и обработает его. Завершив его 
обработку, актор либо переходит к обработке другого сообщения в своем 
почтовом ящике, либо возвращается в неактивное состояние ожидания, 
если почтовый ящик пуст. По ходу обработки сообщений актор может со- 
здавать других акторов, посылать сообщения другим известным ему ак- 
торам или переходить в новое состояние, которое станет текущим после 
обработки следующего сообщения. 


• Процесс — это, как правило, более универсальный виртуальный процес- 
сор, зачастую реализуемый операционной системой в целях содействия 
параллельности. На процессы могут условно накладываться ограничения, 
чтобы они вели себя как акторы. Именно такой тип процесса имеется 
здесь в виду. 


Акторы МОГУТ БЫТЬ ТОЛЬКО ПАРАЛЛЕЛЬНЫМИ 


В определении акторов имеется ряд перечисленных ниже положений. 


» Единого контроля за всем происходящим не существует. Что будет выпол- 
нено следующим, никак не планируется, а передача информации от исход- 
ных данных к окончательным выводимым данным никак не регулируется. 


• Единственное состояние, имеющееся в системе, содержится в сообщениях 
и локальном состоянии актора. Сообщения могут быть проанализированы 
только при прочтении их получателем, а локальное состояние за предела- 
ми актора недоступно. 


2 Апріе-Магіе ЮеІѕапќе — американская писательница в жанре научной фантастики, по- 
борница целостного образа жизни. — Примеч. пер. 
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= Все сообщения являются однонаправленными, и ответы на них не предус- 
мотрены. Если же требуется, чтобы актор возвратил ответ, в посылаемом 
сообщении следует указать адрес своего почтового ящика, и тогда актор 
(в конечном итоге) отправит ответ как обычное сообщение в указанный 
ПОЧТОВЫЙ ЯЩИК. 


• Актор поочередно полностью обрабатывает каждое сообщение. 


Таким образом, акторы выполняются одновременно, асинхронно и не исполь- 
зуют совместно ничего общего. Если бы в системе было достаточно физических 
процессоров, на каждом из них можно было бы выполнять отдельный актор. 
При наличии единственного процессора требуется соответствующая выполня- 
ющая среда, способная переключать контекст с одного актора на другой. Но в 
любом случае код, выполняемый акторами, остается одним и тем же. 


Пользуйтесь акторами, чтобы достичь параллельности без 
общего состояния 


Простой АКТОР 


Итак, реализуем рассмотренный ранее пример ситуации в ресторане, исполь- 
зуя акторов. В данном случае у нас будут три актора: посетитель, официант и при- 
лавок с пирогом. Общий поток сообщений будет выглядеть следующим образом. 


ә Мы (подобно некоей внешней богоподобной силе) внушаем посетителю, 
что он проголодался. 


• В ответ посетитель заказывает официанту пирог. 


® Официант обращается к прилавку, чтобы взять кусок пирога и принести 
его посетителю. 


е Если на прилавке имеется кусок пирога, он будет отправлен посетителю, а 
официант уведомлен, что пирог следует внести в счет. 


® Если же пирога на прилавке нет, официант будет уведомлен об этом, ему 
придется извиниться перед посетителем. 


Мы решили реализовать описанный выше алгоритм на языке ]ауа5сирь вос- 
пользовавшись библиотекой Мас. С этой целью мы ввели в исходный код обо- 
лочку, позволяющую реализовать акторов в виде простых объектов, где ключи 
обозначают типы сообщений, принимаемых актором, а значения — функции, 
выполняемые при получении конкретного сообщения. (В большинстве систем 
акторов имеется аналогичная структура, хотя подробности ее реализации зави- 
сят от базового языка.) 


6 См. по адресу НЕЕрз : / /аіёћор. сот/псіћЫгЕ/ пасі. 
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Итак, начнем с посетителя. Он может принимать следующие сообщения. 
® Он проголодался — это сообщение посылается из внешнего контекста. 
® На столе стоит пирог — это сообщение посылается прилавком с пирогом. 


ә Приносятся извинения в связи с тем, что пирога больше не осталось — это 
сообщение посылается официантом. 


Ниже показано, как все это реализуется непосредственно в коде. 


сопсиггепсу/асіогз/іпӣех.јз 


сопзЕ соѕіотегАсіог = { 
"Һопдгу Ёог ріе': (759, сёх, ѕіаёе) => { 
геёоџгп аі ѕраїсћ (ѕїіаїёе.маіїіег, 
{ суре: "огаег", сиѕіотег: сёх.зе1ЁЕ, мапіѕ: 'ріе! }) 
}, 
"риб оп ёаріе': (тѕд, сіх, зёаїе) => 
сопѕо1е. 109 ('$ { сіх.ѕе1Ё.патме} зеез 
"$ {т59.Ғооа)}" арреаг оп һе ф$аЪ1е'), 
'по ріе 1еЁё': ( тѕд, сіх, зѕіаіе) => 
сопзо1е.1од ('${сЕх.зе1Ё.паме} ѕи1кѕ...!') 


} 


Любопытная ситуация возникает в том случае, когда мы получаем сообщение 
о том, что посетитель проголодался и жаждет пирога, и посылаем сообщение 
официанту. (Ниже будет показано, откуда актору посетителя известно об акторе 
официанта.) Ниже приведен код, реализующий актора официанта. 


сопсоггепсу/асіогз/іпӣех.јз 


сопзі маііегАсіог = { 
"огаег"®: (юмѕд, сіх, ѕїаіёе) => { 
1Е (пза.мапез == "ріе") { 
аіѕраісћ (ѕїасе.ріеСаѕе, 
{ суре: "дес $11се", сиѕіотег: тмѕд.сиѕіопег, 
маіїег: сех.зе1Е }) 
} 
е1зе { 
сопѕо]іе.аіг (' роп'і Кпом Вом їо огаег ${пза.мапе$}'); 
} 
}, 


"ааа ёо огаег": (тѕд, сіх) => 
соп5о1е.1о4 ('Маііег аааѕ $ {тѕд. Ғооа} 
со $ {(м759.сиѕіотег.папе}'ѕ огаег'), 


"еггог"®: (тѕд, сіх) => { 
аізраїсһ (м759.сциѕіотег, { іуре: 'по ріе ІеЁё', м59: пза.мза }); 
сопзѕо1е.109 ('\пТЬе маіег аро1одіғеѕ фо 
$ {мѕ9.сиѕіотег.пате}: ${пза.мза}') 
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Получив от посетителя сообщение 'ог4ег' (заказ), официант проверяет, за- 
прошен ли пирог. Если это именно так, он посылает запрос прилавку с пирогом, 
передавая ссылки как на самого себя, так и на посетителя. 

Прилавок с пирогом находится в состоянии, содержащем массив всех нахо- 
дящихся на нем кусков пирога. (Ниже будет показано, как устанавливается это 
состояние.) Когда прилавок получает сообщение 'деї з311се' (взять кусок пи- 
рога) от официанта, он выясняет, осталось ли сколько-нибудь кусков пирога. 
Если осталось, то он передает кусок пирога посетителю, сообщает официанту о 
необходимости обновить заказ и, наконец, возвращает состояние, содержащее 
на один кусок пирога меньше. Ниже показано, как все это реализуется непо- 
средственно в коде. 


сопсоггепсу/асіогз/іпіех .јз 


сопѕё ріеСаѕеАсіог = { 
"сес $11се': (тѕд, сопіехі, ѕіаёе) => { 
1Е (5№аёе.511ісеѕ.1епаёєһ == 0) { 
аіѕраісћһ (мтѕӯ9.маіёег, { ёуре: 'еггог', тѕд: "по ріе 1еЁ*", 
сцѕіотег: тѕа.сиѕіотег }) 
геёџгп ѕіаѓе 
} 
е1зе { 
уүаг $1]1се = ѕіаёе.51ісеѕ.ѕһіЁі () + " ріе $11се"; 
аіѕраёсћ (мѕӯ.сиѕіотег, ёуре: 'риі оп +ёар1е!', Ғооа: $11се }); 
аіѕраёсһ (мѕад.маііег, { їуре: ' ааа ёо огаег', Еооа: ѕіісе, 
сиѕіотег: тѕд.соиѕіотмег }); 
геёигп ѕіаѓе; 


} 


Несмотря на то что одни акторы зачастую динамически запускаются другими 
акторами, в данном случае ради простоты это делается вручную. При этом каж- 
дому актору передается некоторое исходное состояние, как поясняется ниже. 


• Прилавок получает первоначальный список находящихся на нем кусков 
пирога. 


е Официанту передается ссылка на прилавок с пирогом. 
® Посетителям передается ссылка на официанта. 
сопсиггепсу/асіёогѕ/іпдех. јз 

сопзі асіогбузѕіет = ѕїагї () ; 


Іеє ріеСаѕе = ѕіагі асіог ( 
асіогдуѕіет, 
'р1е-сазе', 
р1еСазеАсфохг, 
{ 511сеѕ: ["арр1е", "реасһ", "сһеггу"] }); 
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1еЕ маіёег = ѕіагі асіог ( 
асіогбуѕіет, 
"маіїёег', 
маіегАсіог, 
{ ріеСаѕе: ріеСазѕе }); 


Іеё с1 = ѕіагі асіог (асіогбузёет, ' соѕзіотег1!', 
сиѕіотегАсіог, { маіїег: маііег }); 


Іеї с2 


ѕіагі асіог (асіогбуѕіёет, 'сиѕіотег2', 
сиѕіотегАсіог, { маііег: маііёег }); 


Наконец, запустим все описанное выше в действие. Посетители ресторана 
проголодались. Первый посетитель заказывает три куска пирога, а второй — 
два. Ниже показано, как это реализуется непосредственно в коде. 


сопсиггепсу/асіогз/іпіех. јзѕ 


аіѕраісћ (с1, 
аіѕраісћ (с2, 
аіѕраісћ (с1, 
аіѕраісћ (с2, 
аіѕраісћ (с1, 
ѕ1еер (500) 
„. Срел (() => { 
ѕіор (асіогдЅузіет) ; 


уре: 'Бопагу Еог р1е'!, маііег: маііег }); 
уре: 'Бопагу Рог ріе', маііег: маіїіег }); 
уре: 'Һипагу Еог р1е', маііег: маіёег }); 
уре: 'һопагу Ёог р1е', маііег: маііег }); 
уре: 'Бопагу Еог ріе', маіёег: маііег }); 


}) 


Выполнив приведенный выше код, можно увидеть, как акторы обмениваются 
сообщениями’. Хотя порядок их действий у вас может оказаться иным. 


$ поде іпӣех.јз 

сциѕёотег1і ѕееѕ "арр1е ріе $11се" арреаг оп їһе фар1е 
сиѕіотег2 ѕееѕ "реасћһ ріе $11се" арреаг оп һе їар1е 
Маіёег аааѕ арр1е ріе ѕіісе іо сиѕіотег1'ѕ огаег 
Каіег аааѕ реасћһ ріе ѕіісе їо сизбомег2'$ огаег 
сиѕіомегі ѕееѕ "сһеггу ріе $11се" арреаг оп {һе іар1е 
Маіёсег аааѕ сһеггу ріе $11се іо сиѕіотег1'ѕ огаег 


Тһе маііег аро1одіғеѕ іо сиѕіомег1: по ріе Іеї 
сиѕіотегі ѕи1кѕ... 


Тһе маіїіег аро1одіғеѕ іо сазбомег2: по ріе Іеї 
сизёотмег2 зи1Кз...8 


7 Чтобы выполнить этот код, вам потребуются также функции-оболочки, которые здесь 
не показаны. Их можно загрузить по адресу ВЕЕрз: / /тедіа.ргадргоч. сот/ёіб1езѕ/ 
ерр20/соаде/сопсиггепсу/асіогѕ/іпаех.ј ѕ. 


8 Первый посетитель видит, как на его столе появляется "кусок яблочного пирога" 
Второй посетитель видит, как на его столе появляется "кусок персикового пирога" 
Официант вносит кусок яблочного пирога в заказ первого посетителя 

Официант вносит кусок персикового пирога в заказ первого посетителя 

Первый посетитель видит, как на его столе появляется "кусок вишневого пирога" 
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ОТСУТСТВИЕ ЯВНОЙ ПАРАЛЛЕЛЬНОСТИ 


В модели акторов отпадает всякая необходимость писать код, поддерживаю- 
щий параллельность, поскольку отсутствует общее состояние. Нет также необ- 
ходимости программировать явным образом логику, реализующую всю после- 
довательность действий от начала и до конца, поскольку акторы выясняют эту 
последовательность сами, исходя из получаемых ими сообщений. 

Здесь нет никакого упоминания о базовой архитектуре. Такой набор компо- 
нентов может быть в равной степени пригодным для однопроцессорных, мно- 
гоядерных систем или множества подключенных к сети машин. 


ЕвЕАМС ПОДГОТАВЛИВАЕТ ПОЧВУ 


Язык Еапе и его выполняющая среда служат характерными примерами реа- 
лизации акторов, несмотря на то, что изобретатели ЕЙапр не читали оригиналь- 
ную статью об акторах. И хотя акторы называются в языке Епапр процессами, 
тем не менее их нельзя считать обычными процессами операционной системы. 
Вместо этого процессы в ЕЙап?, подобно рассмотренным выше акторам, легко- 
весны (на одной машине можно выполнять их миллионами) и обмениваются 
отправляемыми сообщениями. Каждый такой процесс изолирован от остальных 
процессов, а следовательно, у них нет общего состояния. 

В выполняющей среде языка Егапе реализуется также система контроля над 
сроками действия процессов, потенциально перезапускающая один процесс или 
ряд процессов в случае отказа. Кроме того, в языке Епапр поддерживается “го- 
рячая” загрузка кода, позволяющая заменять код в системе, не останавливая ее 
работу. Наконец, система языка Епапұ выполняет едва ли не самый надежный в 
мире код с показателем безотказности порядка 99,9999999%. 

Но язык ЕЙап8 и производный от него язык Ех! не единственны в своем 
роде, поскольку акторы реализованы и в большинстве других языков. Далее они 
будут рассмотрены с точки зрения реализации параллельности. 


Официант вносит кусок вишневого пирога в заказ первого посетителя 


Официант извиняется перед первым посетителем за то, что пирога больше не осталось 
Первый посетитель сердится... 


Официант извиняется перед вторым посетителем за то, что пирога больше не осталось 
Второй посетитель сердится... 
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Другие разделы, связанные с данной темой 
ө Тема 28. Развязывание, глава 5 “Гибкость или ломкость”, 


® Тема 30. Преобразовательное программирование, глава 5 “Гибкость или 
ломкость’. 


ә Тема 36. Классные доски. 


Задачи 


е Имеется ли у вас в настоящее время такой код, в котором взаимное исклю- 
чение применяется для защиты общих данных? Почему бы вам не опробо- 
вать прототип того же кода, написанного с помощью акторов? 


® В коде, реализующем акторов для контроля над описанной выше ситуа- 
цией в ресторане, поддерживаются заказы кусков пирога. Расширьте этот 
код таким образом, чтобы дать посетителям ресторана возможность зака- 
зывать яблочный пирог с мороженым, а отдельным агентам — манипули- 
ровать кусками пирога и шариками мороженого. Устройте все так, чтобы 
обрабатывать ситуацию, когда израсходуется пирог или мороженое. 


О О а КА А 


КЛАССНЫЕ ДОСКИ 


“И писали напротив лампады на извести 
чертога царского...” 


Книга пророка Даниила, глава 5 


Рассмотрим, каким образом детективы могли бы пользоваться классной до- 
ской для координирования действий в расследовании убийства. Главный инс- 
пектор устанавливает для начала крупную черную доску в зале совещаний и 
пишет на ней единственный вопрос: 


Шалтай-Болтай (мужчина, яйцо): несчастный случай или убийство? 


Действительно ли Шалтай упал сам или его толкнули? Каждый детектив мо- 
жет внести свой вклад в раскрытие тайны этого потенциального убийства, доба- 
вив факты, показания свидетелей, любые данные судебной экспертизы, которые 
могут появиться, и т.д. По мере накопления данных каждый детектив может 
заметить во всем этом определенную связь и написать на доске свои наблюде- 
ния или предположения. И этот процесс продолжается со всеми отклонениями 
и участием самых разных людей и посредников до тех пор, пока дело не будет 
закрыто. Пример классной доски для данного случая приведен на рис. 6.1. 
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Шалтай-Болтай (мужчина, яйцо): несчастныйслучай? убийство? | 
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Рис. 6.1. Кто-то обнаружил связь между карточными долгами Шалтая-Болтая и 


зарегистрированными телефонными звонками. Вероятно, его могли запугивать по телефону 


Ниже перечислены основные свойства метода классной доски. 


Ни одному из детективов совсем не обязательно знать о существовании 
любых других детективов. Они просто следят за новой информацией на 
классной доске и пишут на ней свои изыскания. 


Детективы могут иметь подготовку в самых разных дисциплинах, разные 
уровни образования и опыта, а возможно, и вообще не работать на одном 
и том же участке территории. Они разделяют общее желание раскрыть 
преступление, и только. 


В ходе данного процесса разные детективы могут приходить и уходить, 
и работать посменно. 


На информацию, размещаемую на классной доске, не накладывается ника- 
ких ограничений. Это могут быть фотографии, свидетельские показания, 
вещественные доказательства и т.д. 


Классная доска служит в данном случае формой пассивной параллельности, 
где детективы являются независимыми процессами, агентами, акторами и т.д. 
Одни из них размещают добытые факты на классной доске, а другие берут эти 
факты с доски и, возможно, объединяют или обрабатывают их, а также указыва- 
ют дополнительные сведения на доске. И постепенно доска помогает им прийти 
к общему заключению по поводу расследуемого преступления. 

Автоматизируемые системы классных досок первоначально применялись 
в приложениях искусственного интеллекта, где решались крупные и сложные 
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задачи, включая распознавание речи, системы формирования рассуждений на 
основе базы данных и т.д. Одна из первых таких систем называлась [1п4Ча и была 
разработана Дэвидом Гелернтером. Факты хранились в ней в виде типизирован- 
ных кортежей. Приложения могут записывать новые кортежи в систему іпда 
и запрашивать существующие кортежи, используя определенную форму сопос- 
тавления с шаблоном. 

Позднее появились распределенные системы типа классных досок, например 
Гауа5расе$ и Т Ѕрасеѕ. С помощью этих систем можно сохранять на классной 
доске не только данные, но и активные объекты ]ауа, а также извлекать их по 
частично совпадающим полям (через шаблоны и метасимволы подстановки) 
или подтипам. Допустим, имеется тип данных Аоіћог, являющийся подтипом, 
производным от типа Регзоп. На классной доске, содержащей объекты типа 
Регѕоп, можно производить поиск, используя шаблон типа Аџёһог со значе- 
нием Ѕћһакеѕреаге в поле 1а5Маме. В результате такого поиска будет обна- 
ружен автор Уильям Шекспир, но не садовник Фред Шекспир. Мы считаем, что 
такие системы не нашли широкого применения отчасти потому, что так и не 
выработалась потребность в определенного рода параллельной коллективной 
обработке. 


КЛАССНАЯ ДОСКА В ДЕЙСТВИИ 


Допустим, требуется написать программу, принимающую и обрабатываю- 
щую заявки на залог или заем. Законы, регулирующие данную сферу, одиозно 
сложны, причем в них имеются расхождения на уровне штатов и федерально- 
го правительства США. В частности, заимодавец должен подтвердить, что он 
владеет некоторыми преданными гласности предметами недвижимости, а также 
запросить определенные сведения, но не задавать ряд других вопросов и т.д. 

Помимо проблем текущего законодательства, в данном случае придется ре- 
шать следующие задачи. 


® Ответы могут поступать в любом порядке. Например, обработка запросов 
на проверку кредитной истории или правового статуса может отнять не- 
мало времени, тогда как Ф.И.О. и адрес могут быть сверены немедленно. 


е Сбор данных может выполняться разными людьми, рассредоточенными 
по разным учреждениям и в разных часовых поясах. 


Ф Некоторые данные могут быть собраны автоматически другими система- 
ми, а также могут поступать асинхронно. 


• Тем не менее одни данные могут быть собраны независимо от других. На- 
пример, начать проверку правового статуса владельца автомобиля, воз- 
можно, не удастся до тех пор, пока не будут подтверждены права владения 
или страховки. 
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® Поступление новых данных может поднимать новые вопросы и правила. 
Допустим, в результате проверки кредитной истории возвращается отнюдь 
не блестящий отчет, и поэтому придется заполнить еще пять дополнитель- 
ных форм и взять образец крови. 


Используя систему управления потоком операций, можно попытаться рас- 
смотреть все возможные сочетания и обстоятельства. И хотя имеется немало 
таких систем, они могут быть довольно сложными для проектирования и про- 
граммирования. Ведь нормативы изменяются, а поток операций может быть 
реорганизован. Так, если сменятся технологические процедуры, жестко закоди- 
рованный код, возможно, придется полностью переписать. 

В сочетании с механизмом соблюдения правил, инкапсулирующих законные 
требования, классная доска является изящным решением обнаруженных здесь 
трудностей. Порядок поступления данных не имеет особого значения: как толь- 
ко на доске будет размещен некоторый факт, он может привести в действие со- 
ответствующие правила. Ответная реакция организуется так же легко: результат 
соблюдения любого набора правил может быть размещен на классной доске, 
приводя в действие другие подходящие правила. 


Пользуйтесь классными досками для координации 
потока выполнения 


СИСТЕМЫ ОБМЕНА СООБЩЕНИЯМИ МОГУТ 
БЫТЬ ПОДОБНЫ КЛАССНЫМ ДОСКАМ 


На момент написания второго издания данной книги многие приложения 
проектировались с помощью небольших развязанных служб, обменивавшихся 
данными через некоторую форму системы обмена сообщениями. Такие систе- 
мы (например, Каа и МАТ$) способны на гораздо большее, чем просто ор- 
ганизовывать обмен сообщениями между сторонами А и В. Они, в частности, 
обеспечивают сохраняемость (в форме журнала регистрации событий), а также 
возможность извлекать сообщения посредством определенной формы сопостав- 
ления с шаблоном. Это означает, что их можно применять в качестве системы 
классной доски и/или платформы для выполнения целого ряда акторов. 


Но НЕ ВСЕ ТАК ПРОСТО... 


Подходы к архитектуре с использованием актора, классной доски и/или мик- 
рослужбы устраняют целый класс потенциальных затруднений, обусловленных 
в приложениях параллельностью. Но данное преимущество дается не бесплат- 
но. Такие подходы труднее осмыслить, поскольку они действуют по большей 
части косвенно. Но при этом можно обнаружить, что они помогают организо- 
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вать и вести центральное хранилище форматов сообщений и/или прикладные 
интерфейсы АРІ, особенно если в таком хранилище можно автоматически сге- 
нерировать код и документацию. Потребуется также хороший инструментарий 
для отслеживания сообщений и фактов по мере их продвижения через систе- 
му. (В качестве удобной методики можно ввести однозначный идентификатор 
трассировки при инициализации конкретной прикладной функции, а затем рас- 
пространить его среди всех заинтересованных акторов. Это позволит восстано- 
вить то, что происходит, из файлов регистрации.) 

Наконец, развертывание и сопровождение такого рода системы может ока- 
заться затруднительным, поскольку в ней немало подвижных частей. Этот не- 
достаток в какой-то степени уравновешивается тем, что система оказывается 
более детализированной и может быть обновлена заменой отдельных акторов, 
а не целиком. 


Другие разделы, связанные с данной темой 


е Тема 28. Развязывание, глава 5 “Гибкость или ломкость”. 


Тема 29. Манипулирование реальным миром, глава 5 “Гибкость или лом- 
> 
кость”, 


Тема 33. Разрывание временного связывания. 


Тема 35. Акторы и процессы. 


Упражнения 


24. Подойдет ли система типа классной доски для перечисленных ниже прило- 
жений? Объясните, почему она может подойти или не подойти. 


- Обработка изображений. Здесь желательно иметь ряд параллельных 
процессов, которые выбирают фрагменты изображения, обрабатывают 
их и возвращают готовые фрагменты обратно. 


- Групповое ведение календаря. Здесь требуется запланировать совеща- 
ние участников проекта, рассредоточенных по всему миру, в разных ча- 
совых поясах и говорящих на разных языках. 


~ Инструментальное средство текущего контроля сети. Здесь система 
собирает статистические данные производительности и отчеты об от- 
казах, используемые посредниками для обнаружения неисправностей в 
системе. 


Задачи 


ә Пользуетесь ли вы системами классных досок на практике, в том числе 
доской семейных объявлений на холодильнике или белой доской на ра- 
боте? Чем они эффективны? Появляются ли вообще на них сообщения в 
согласованном формате и насколько это важно? 


ГЛАВА 7 


ПО ХОДУ ко 


Житейская мудрость гласит: как только проект доходит до стадии кодиро- 
вания, работа становится в основном механическим воплощением проектного 
решения в выполняемые операторы. На наш взгляд, такое отношение к проекту 
служит самой главной причиной его неудачного окончания, а многие спроекти- 
рованные подобным образом системы оказываются скверными, неэффективны- 
ми, плохо структурированными, не поддающимися сопровождению или просто 
наносящими ущерб. 

Кодирование не механично. Если бы это было именно так, то все инструмен- 
тальные средства САЗЕ, на которые возлагались большие надежды еще в начале 
1980-х годов, уже давно заменили бы собой программистов. По ходу работы 
приходится каждую минуту принимать решения, требующие тщательного об- 
думывания и оценивания, чтобы написанная в итоге программа работала долго, 
надежно и продуктивно. 

Не все решения даже просто здравы, поэтому лучше обуздывать себя, при- 
слушиваясь к своим инстинктам, как поясняется в соответствующем разделе. 
В этом разделе будет показано, как прислушиваться к своим инстинктам более 
осторожно и анализировать способы активной реакции на иногда пустячные 
мысли. 

Но необходимость прислушиваться к инстинктам совсем не означает, что 
можно просто летать на автопилоте. Те разработчики, которые не обдумывают 
активно свой код, программируют по совпадению. Это означает, что написанный 
код может работать, но по какой именно причине — непонятно. Поэтому в раз- 
деле “Программирование по совпадению” отстаивается более положительный 
подход к процессу программирования. 

Несмотря на то что код, который мы пишем, выполняется быстро, мы вре- 
мя от времени разрабатываем алгоритмы, способные застопорить работу даже 
самых быстродействующих процессоров. В связи с этим в разделе “Быстродейс- 
твие алгоритмов” обсуждаются способы оценивания быстродействия написан- 
ного кода и даются некоторые рекомендации относительно выявления потенци- 
альных осложнений в нем еще до того, как они возникнут. 
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Прагматичные программисты умеют критически осмысливать весь код, 
включая и свой собственный. Они постоянно ищут основания для совершен- 
ствования своих программ и проектов. Поэтому в разделе “Рефакторинг” будут 
рассмотрены методики, помогающие постоянно исправлять существующий код 
по ходу его написания. 

Тестирование означает не столько обнаружение программных ошибок, сколь- 
ко получение ответной реакции на свой код, включая особенности архитектуры, 
прикладного интерфейса АРІ, связывания и т.д. Следовательно, основные вы- 
годы из тестирования проявляются тогда, когда тесты сначала обдумываются, 
а затем пишутся, но не лишь тогда, когда они выполняются. Именно этот при- 
нцип и поясняется в разделе “Тестировать, чтобы кодировать’. 

Но, безусловно, когда вы тестируете свой код, вы можете привнести в ре- 
шаемую задачу свои пристрастия. Поэтому в разделе “Тестирование на основе 
свойств” показано, как заставить компьютер выполнять обширное тестиро- 
вание автоматически и обрабатывать неизбежно возникающие программные 
ошибки. 

Очень важно писать удобочитаемый и понятный код. Окружающий мир по- 
лон злоумышленников, активно пытающихся взломать действующую систему 
и нанести ей ущерб. Поэтому в разделе “Будьте осторожны” рассматриваются 
самые элементарные методики и подходы, помогающие организовать надежную 
‚ защиту системы от взлома. 

Наконец, одну из самых больших трудностей в разработке программного 
обеспечения вызывает именование элементов кода. Разработчикам приходится 
именовать немало элементов кода, и зачастую выбираемые ими имена определя- 
ют ту реальность, которую они создают. Поэтому по ходу кодирования следует 
постоянно иметь в виду любые возможные семантические отклонения. 

Большинство из нас водят автомобиль в основном машинально, не давая 
явно команду своей ступне нажать педаль или руке повернуть руль. Мы лишь 
задумываемся о необходимости притормозить и повернуть направо или налево 
в нужный момент. Но грамотные и осторожные водители постоянно оценивают 
ситуацию на дороге, упреждая потенциальные осложнения и тем самым оказы- 
ваясь в лучшем положении, даже если произойдет что-нибудь непредвиденное. 
Это же относится и к кодированию, которое в основном оказывается рутинным 
занятием, но все же не зевайте — это поможет вам предотвратить возможные 
неприятности. 
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ПРИСЛУШИВАЙТЕСЬ К СВОИМ ИНСТИНКТАМ 


“Только люди способны непосредственно рассматривать 
что-то, имея всю необходимую информацию, 
чтобы сделать точный прогноз, а возможно, 

даже сделать его моментально и затем сказать, 
что дело обстоит иначе”. 


Гэвин де Беккер, “Дар страха” 


Труд всей жизни Гэвина де Беккера помогает людям защищать себя. Свои 
взгляды на вопросы защиты от насилия он изложил в книге Тйе СТ оў Ееат: Апӣ 
Ошет $итута] $іспа1ѕ Тһаі РгоесЕ Ц; рот МіоІепсе [де 98]. Одна из главных тем 
этой книги касается того обстоятельства, что люди как высокоразвитые сущес- 
тва научились пренебрегать своей животной сущностью, своими инстинктами и 
первобытными повадками. Он утверждает, что большинство людей, на которых 
нападают на улице, чувствуют себя неуютно или нервничают перед нападением. 
И эти люди просто внушают себе, что не стоит вести себя так глупо. И тогда из 
темного прохода возникает чужая фигура... 

Инстинкты являются попросту реакцией на образцы поведения, хранящиеся 
в нашем бессознательном. Одни из них врожденные, другие приобретены через 
повторение. По мере накопления опыта программирования в уме незаметно от- 
кладываются слоями знания о том, что пригодно и что непригодно, о вероятных 
причинах типов ошибок и обо всем, что подмечается изо дня в день. Эта часть 
ума действует подобно экранной кнопке сохранения файла, которую вы нажима- 
ете, когда прекращаете интерактивную переписку с кем-нибудь в оперативном 
режиме, даже не осознавая того, что делаете. 

Независимо от происхождения инстинктов, им присуща одна общая особен- 
ность: они безмолвны. Инстинкты вызывают ощущение, а не мысль, и поэтому, 
когда возбуждается инстинкт, вы не видите никакой вспыхивающей лампочки с 
крупным заголовком вокруг. Вместо этого вы начинаете нервничать, испытыва- 
ете недомогание и просто чувствуете, что предстоит слишком много работать. 

Вся хитрость здесь в том, чтобы сначала заметить, что это происходит, а за- 
тем выяснить причину. Рассмотрим для начала пару типичных случаев, когда 
внутренний инстинкт пытается нам что-то подсказать, а затем обсудим, как вы- 
зволить свой инстинктивный ум из его защитной оболочки. 


Боязнь ПУСТОЙ СТРАНИЦЫ 


Все испытывают страх перед пустым экраном, где одиноко мигает курсор. 
Начало нового проекта (и даже нового модуля в уже существующем проекте) 
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может стоить немалых нервов. Поэтому многие из нас предпочитают отсрочить 
первоначальное обязательство приступить к делу. На наш взгляд, это связано с 
двумя затруднениями, для которых имеется одно и то же решение. 

Одно затруднение связано с тем, что наш инстинкт пытается нам что-то под- 
сказать. Но под самой личиной восприятия скрывается какое-то сомнение, что 
очень важно. Всякому разработчику приходится опробовать разные подходы, 
чтобы выяснить, какие из них годятся, а какие непригодны. И подобным обра- 
зом накапливаются знания и опыт. Так, если вы чувствуете неотвязное сомнение 
или испытываете нежелание решать какую-то задачу, то вполне возможно, что 
это вам подсказывает ваш опыт. Прислушайтесь к нему. Не спешите совершать 
явно неверный шаг, а подождите, пока ваши сомнения не оформятся в нечто 
более ощутимое, чтобы их можно было разрешить. Дайте волю вашим инстин- 
ктам, чтобы они способствовали вашим поступкам. 

Другое затруднение более прозаично. Вы можете просто бояться совершить 
ошибку. И это вполне обоснованное опасение. Ведь разработчики немало вкла- 
дывают в свой код и поэтому могут воспринимать ошибки в нем как отражение 
их компетентности. В этом, вероятно, есть также элемент синдрома самозванца. 
Разработчикам может показаться, что данный проект им не под силу. Они нев 
состоянии найти способ довести его до конца. Зайдя слишком далеко, они вы- 
нуждены признать, что потерялись. 


БорЬБА С СОБОЙ 


Иногда код просто вылетает из вашего ума прямо в текстовый редактор, а 
идеи воплощаются в код без всяких усилий. 

А порой кодирование воспринимается как ходьба в гору по колено в грязи. 
Каждый шаг требует громадных усилий, а через каждые три шага вы соскаль- 
зываете на два шага назад. 

Но, будучи профессионалом, вы упорно продвигаетесь по этой грязи шаг за 
шагом вперед, поскольку вам нужно делать свое дело. К сожалению, это, веро- 
ятно, именно то, чего вам не следует делать. 

Ваш код пытается вам что-то подсказать. Он говорит, что его можно было бы 
написать проще, чем это сделано. Возможно, структура или архитектура была 
выбрана неверно, а может быть, неверной оказалась сама решаемая задача или 
же вы просто создаете нечто, подобное муравейнику, достойному обитающих в 
нем насекомых. Независимо от конкретной причины, ваши инстинкты воспри- 
нимают ответную реакцию написанного кода, отчаянно пытающегося обратить 
на себя ваше внимание. 
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КАК ПРИСЛУШИВАТЬСЯ К СВОИМ ИНСТИНКТАМ 


Мы уже не раз подчеркивали, что необходимо прислушиваться к своим ин- 
стинктам, к своему бессознательному, первобытному уму. А существующие для 
этого методы всегда одинаковы. 


Прислушивайтесь к своим внутренним чувствам 


Прежде всего, приостановитесь в своей работе. Уделите время и место, что- 
бы позволить вашему мозгу самоорганизоваться. Перестаньте думать о коде и 
займитесь на время чем-нибудь откровенно бездумным и далеким от мысли о 
клавиатуре. Прогуляйтесь, пообедайте, побеседуйте с кем-нибудь, а может быть, 
даже вздремните немного. Дайте мыслям самим непринужденно проникнуть 
сквозь слои вашего ума. И когда они в конечном счете достигнут уровня вашего 
сознания, вы переживете один из моментов озарения. 

Если этот способ не сработает, попытайтесь облечь возникшее затруднение 
во внешнюю форму. Сделайте зарисовки о написанном вами коде или объясни- 
те его своему коллеге (желательно не программисту) либо своему резиновому 
утенку. Раскройте разные участки своего ума для возникшего затруднения и 
выясните, какой из них лучше всего подойдет для того, чтобы разрешить дан- 
ное затруднение. Мы уже потеряли счет беседам, в ходе которых один из нас 
объяснял другому возникшее у него затруднение и неожиданно восклицал: “Ах, 
да! Конечно!’, сразу прерывая беседу, чтобы немедля устранить обсуждавшееся 
затруднение. 

Вполне возможно, что вы уже опробовали описанные выше способы на прак- 
тике и все равно не вышли из затруднения. В таком случае время действовать, 
и мы должны сказать вашему уму, что все, что вы собираетесь делать, не имеет 
никакого значения. И для этого мы прибегнем к прототипированию. 


ВРЕМЯ ИГРАТЬ! 


Авторам этой книги не раз приходилось часами глядеть на чистый экран 
текстового редактора. Сначала мы набирали какой-нибудь код, затем глядели 
в потолок, делали очередной глоток кофе, снова набирали немного кода, после 
этого читали забавный рассказ, например, о коте с двумя хвостами, опять наби- 
рали еще немного кода и, наконец, выделив весь исходный текст, удаляли его, 
начиная все с самого начала. И все это повторялось снова и снова. 

С годами у нас выработался вполне работоспособный, на наш взгляд, метод 
взлома сознания. Внушите себе, что вам требуется создать прототип чего-ни- 
будь. Если перед вами пустой экран, найдите такую особенность своего про- 
екта, которая требует исследования. Это может быть, например, новый каркас, 
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применяемый в вашем проекте, и вам нужно выяснить, каким образом в нем 
осуществляется привязка данных; или же новый алгоритм, который требуется 
испытать на работоспособность в крайних случаях. А возможно, вам требуется 
опробовать два разных стиля взаимодействия с пользователем. Если, работая с 
существующим кодом, вы испытываете сопротивление с его стороны, сохраните 
его где-нибудь и создайте прототип, выполняющий аналогичные функции. 

С этой целью выполните следующие действия. 


1. Напишите фразу “Я создаю прототип” на клейкой бумажке для заметок и 
прикрепите ее к боковой стороне экрана своего монитора. 


2. Напомните себе, что прототипы обречены на неудачу и выбрасывание, 
даже если они окажутся удачными. А самое главное, что в этом не следует 
усматривать никакого недостатка. 


3. Создайте в пустом буфере текстового редактора комментарии, описыва- 
ющие одним предложением, что именно вам требуется изучить или сде- 
лать. 


4. Начните программировать. 


Если вас начнут мучить сомнения, посмотрите на бумажку на мониторе. 
А если по ходу кодирования неотвязное сомнение неожиданно оформится в яс- 
ный вопрос, то разрешите его. Если же, дойдя до конца своего эксперимента, 
вы все еще будете испытывать неловкость, начните все с самого начала, сделав 
перерыв на прогулку, беседу и отдых. 

Но, как показывает наш опыт, в какой-то момент по ходу создания первого 
прототипа вы с удивлением обнаружите, что, напевая под музыку, с удовольс- 
твием пишете код. Ваша нервозность исчезнет без следа, вытесненная неуемным 
желанием создать нечто конкретное. На этой стадии вы уже будете знать, что 
нужно делать. В таком случае — удалите код прототипа, выбросите бумажку для 
записей в мусорную корзину и заполняйте экран текстового редактора блестя- 
щим новым кодом. 


НЕ ТОЛЬКО СВОЙ КОД 


Львиная доля обязанностей разработчиков приходится на работу с уже су- 
ществующим кодом, нередко написанным другими людьми. У этих людей были 
не такие инстинкты, как у вас, и поэтому их решения были иными. И хотя эти 
решения совсем не обязательно неудачные, они все же иные. 

Чужой код можно читать механически, скрупулезно делая заметки, которые 
кажутся важными. Хотя это и рутинный, но все же работоспособный метод. 

С другой стороны, можно попытаться провести эксперимент. Если вы обна- 
ружите, что код кажется странным — сделайте соответствующие заметки. Затем 
продолжите дальше и поищите возможные шаблоны. Если вам удастся выяс- 
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нить, чем руководствовались программисты при написании анализируемого 
кода именно так, а не иначе, — возможно, вам будет легче его понять. И тогда 
вы сможете вполне осознанно применять шаблоны, которые подразумевались 
при разработке данного кода. Более того, вы даже можете узнать что-то новое 
для себя, анализируя чужой код. 


НЕ только код 


Умение прислушиваться к своим инстинктам при программировании являет- 
ся важным навыком, который стоит приобрести. Но такой подход применим и 
к более общей картине. Иногда проектное решение кажется просто неверным, а 
какое-нибудь требование вызывает ощущение неловкости. В таком случае сле- 
дует остановиться и проанализировать свои ощущения. Если вы работаете в 
благоприятной для этого среде, выразите свои ощущения явно и исследуйте их. 
Скорее всего, что-нибудь да промелькнет в темном углу. Прислушайтесь к своим 
инстинктам, чтобы избежать осложнений до того, как они на вас навалятся. 


Другие разделы, связанные с данной темой 
ө Тема 13. Прототипы и памятные записки, глава 2 “Прагматичный подход". 


о Тема 22. Технические дневники, глава 3 “Основные инструментальные 
средства”. 


ә Тема 46. Решение неразрешимых головоломок, глава 8 “До начала проекта”. 


Задачи 


® Есть ли что-нибудь такое, что, на ваш взгляд, должно быть сделано, но 
вы отложили его реализацию на время, поскольку чувствуете боязнь или 
предчувствуете трудности? В таком случае примените методы, описанные 
в этом разделе, уделив им один или два часа и дав себе слово, что, когда 
прозвенит звонок, удалите все, что было сделано за это время. Чему вы в 
итоге научились: 


ПРОГРАММИРОВАНИЕ ПО СОВПАДЕНИЮ 


Приходилось ли вам когда-нибудь смотреть старые черно-белые фильмы о 
войне? Усталое лицо солдата осторожно высовывается из-за кустов. Впереди — 
открытая полянка, но не зарыты ли на ней противопехотные мины или же ее 
можно пересечь безопасно? Ничто не указывает на минное поле: никаких предуп- 
реждающих знаков, колючей проволоки или воронок от взорвавшихся мин. Сол- 
дат прощупывает штыком землю перед собой и отшатывается, ожидая взрыва. 
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А поскольку ничего не происходит, то он шаг за шагом продвигается по полю, 
протыкая землю штыком и ощупывая местность. В конечном счете он убеждает- 
ся, что поле безопасно, и тогда выпрямляется и гордо ступает вперед лишь для 
того, чтобы быть разорванным на куски взорвавшейся миной. Выходит, перво- 
начальные поиски мин ничего не выявили, и солдату просто везло. В конечном 
счете это привело его к ложному заключению и злополучному исходу. 

Разработчики работают в условиях, которые весьма напоминают такие мин- 
ные поля. Каждый день их ожидают сотни ловушек, в которые они могут по- 
пасть. Памятуя о злополучной участи солдата, они должны делать выводы очень 
осторожно. Им, в частности, следует избегать программирования по совпаде- 
нию, полагаясь на удачу и случайный успех, а лучше программировать осто- 
рожно. 


КАК ПРОГРАММИРОВАТЬ ПО СОВПАДЕНИЮ 


Допустим, Фред получил определенное задание. Он набирает некоторый код, 
тестирует его и делает вывод, что код, по-видимому, работоспособен. Далее Фред 
набирает еще немного кода, опробует его и снова находит его работоспособным. 
Через несколько недель программирования в таком стиле получившаяся в ко- 
нечном итоге программа неожиданно перестает работать. Потратив на попытки 
устранить неполадки не один час, Фред все еще не знает причин, по которым 
его программа не работает. Он может потратить немало времени на выявление 
сбойного фрагмента кода, так и не сумев исправить положение. И что бы он ни 
делал, его программа так и не работает нормально. 

Фреду оказались неизвестны причины сбоев в программе потому, что он не 
выяснил, почему она работала прежде. После ограниченного тестирования Фре- 
ду показалось, что программа работает нормально, но это произошло лишь по 
случайному совпадению. Подбодрившись ложной уверенностью, Фред ринулся 
вперед, забыв об осторожности, и наткнулся на мину. Многим умным людям, 
вероятно, известны такие личности, как Фред, а нам известно кое-что получше. 
Мы не полагаемся на случайные совпадения, но так ли это на самом деле? Иног- 
да мы можем поступить таким образом. Ведь часто очень легко спутать счастли- 
вое совпадение с преднамеренным планом действий. Поэтому рассмотрим ряд 
конкретных примеров. 


Случайности реализации 


Они происходят просто потому, что код написан в данный момент именно 
так, а не иначе. И в конечном счете приходится полагаться на недокументиро- 
ванную ошибку или граничные условия. 

Допустим, подпрограмма вызывается с неверными данными. Подпрограмма 
дает некоторый ответ, и вызывающий код опирается на него. Но автор подпро- 
граммы не предусмотрел именно такой режим работы подпрограммы и даже не 
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рассматривал его. Если внести в подпрограмму требующиеся поправки, работа 
вызывающего кода может просто нарушиться. В самом крайнем случае вызы- 
ваемая подпрограмма может быть даже не предназначена делать то, что от нее 
требуется в вызывающем коде. Тем не менее она, по-видимому, вполне работос- 
пособна. Аналогичное затруднение возникает при вызовах не в том порядке или 
же не в том контексте. 

Это похоже на отчаянные попытки Фреда вывести что-нибудь на экран, ис- 
пользуя конкретный каркас СПІ: 

раілі (); 

1пуа11Ча ее (); 

уа11даѓе (); 

геуа1ідаѓе (); 

гераіпі (); 

раіпіІпттеаіаѓе1у(); 


Но перечисленные подпрограммы никогда не создавались для вызова таким 
образом; хотя они выглядят работоспособными, на самом деле это всего лишь 
совпадение. 

Положение усугубляется еще больше, когда окончательный вывод выглядит 
нормально, и Фред даже не попытается вернуться назад и устранить ложные 
вызовы. Он считает, что его программа работает нормально и лучше не трогать 
то, что и так работает. 

Такая нить рассуждений может ввести в заблуждение. В самом деле, зачем 
рисковать, приводя в беспорядок то, что уже работает? Что ж, рассмотрим не- 
сколько следующих причин, дающих ответ на этот вопрос. 


• Программа может на самом деле не работать, а только делать вид, что нор- 
мально работает. 


• Граничное условие, на котором вы основываетесь, может оказаться прос- 
той случайностью. Это означает, что при разных обстоятельствах (разном 
разрешении экрана или количестве ядер процессора) программа может 
работать по-разному. 


• Недокументированное поведение может измениться в следующем выпуске 
библиотеки. 


е Дополнительные и излишние вызовы могут замедлить работу программы. 


® Дополнительные вызовы увеличивают риск добавления новых програм- 
мных ошибок. 


Для кода, который пишется с расчетом быть вызванным из другого кода, мо- 
гут вполне пригодиться основные принципы модуляризации и сокрытия реали- 
зации за небольшими хорошо документированными интерфейсами. А грамот- 
но составленный контракт (см. раздел “Тема 23. Проектирование по контракту” 
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главы 4 “Прагматичная паранойя”) может оказать помощь в устранении недо- 
разумений. Что же касается вызываемых подпрограмм, то следует полагаться 
на документированное поведение. Если же это по какой-нибудь причине невоз- 
можно, то следует задокументировать свое допущение. 


Недостаток точности 


Однажды нам пришлось работать над крупным проектом, выводившим дан- 
ные из очень большого количества запоминающих устройств непосредственно 
в поле. Эти устройства были рассредоточены по разным штатам и часовым по- 
ясам, и каждое из них по различным логистическим и историческим причинам 
было настроено на местное время!. В результате конфликтов в интерпретации 
часовых поясов и несогласованности правил перехода на летнее время результа- 
ты почти всегда получались неверными, хотя и отличались всего лишь на еди- 
ницу. Разработчики данного проекта решили просто прибавлять или отнимать 
единицу, чтобы получить правильный ответ, полагая, что в данной конкретной 
ситуации он будет отличаться всего лишь на единицу. И когда следующая фун- 
кция обнаружит, что значение сместилось на единицу в другую сторону, она 
возвратит его обратно. 

Но смещение результатов “всего лишь” на единицу оказалось совпадением, за 
которым скрывался более глубокий и основательный изъян. В отсутствие надлежа- 
щей модели интерпретации времени вся крупная кодовая база превратилась со вре- 
менем в совершенно непригодную массу операторов +1 и -1. И в конечном счете 
ни один из них не оказался верным, а проект пришлось отправить на свалку. 


Ложные закономерности 


Человеческие существа предрасположены усматривать закономерности и 
причины даже в том случае, когда это всего лишь совпадение. Например, в Рос- 
сии всегда чередовались то лысые, то волосатые правители: на протяжении 200 
лет лысый (или явно лысеющий) государственный деятель сменялся волосатым, 
т.е. совсем не лысым, и наоборот”. 

Но если никому не придет в голову написать код в зависимости от того, будет 
ли следующий правитель России лысым или волосатым, то в некоторых пред- 
метных областях разработчики все время рассуждают именно таким образом. 
Игроки выдумывают закономерности в лотерейных номерах, бросаемых костях 
или крутящихся рулетках, когда на самом деле это статистически независимые 
события. Аналогично в финансовой сфере биржевые операции с акциями и об- 
лигациями полны совпадений, а не вполне различимых закономерностей. 


Примечание стреляного воробья: используйте всемирное координированное время 
(ОТС). 

2 См. по адресу һіірѕ:/ /еп.мікіредіа.огд/мікі/Согге1аёіоп Яоеѕ пої 1тр1у_ 
сацѕаііоп. 
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Журнальный файл, в котором ошибка появляется через каждые 1000 запро- 
сов, может представлять труднодиагностируемое состояние гонки, а возможно, 
просто результат старой программной ошибки. Тесты, которые вроде бы прохо- 
дят на одной машине, могут не пройти на сервере, выявив тем самым отличия в 
обеих средах. А может быть, это простое совпадение. Словом, не допускайте, а 
убеждайтесь. 


Случайности контекста 


Вполне возможны и так называемые “случайности контекста”. Допустим, 
требуется написать служебный модуль. Следует ли полагаться на обязательное 
наличие графического интерфейса пользователя только потому, что этот модуль 
разрабатывается в настоящий момент для СЧІ-среды? Рассчитан ли этот модуль 
на англоязычных пользователей? На обладающих специальной подготовкой? На 
что еще не стоит полагаться, если оно не гарантируется? 

Следует ли полагаться на то, что текущий каталог доступен для чтения? На- 
личествуют ли определенные переменные окружения или файлы конфигурации? 
Будет ли сервер со временем работать точно и с каким допуском? Стоит ли по- 
лагаться на доступность и быстродействие сети? 

Скопировав исходный код, полученный по первому же ответу, найденному в 
сети, можно ли быть уверенным, что он имеет тот же контекст? Не разрабаты- 
вается ли код в стиле карго-культа, просто выполняя имитацию без контекста?? 
Найти подходящий ответ на все эти вопросы еще не означает получить правиль- 
ный ответ. 


Не программируйте по совпадению 


Неявные допущения 


Совпадения могут вводить в заблуждение на всех уровнях: от составления 
требований до тестирования. В частности, тестирование чревато ложными при- 
чинными зависимостями и случайными следствиями. Ведь очень легко предпо- 
ложить, что Х приводит к У, но, как упоминалось ранее в совете 34 из раздела 
“Тема 20. Отладка” главы 3 “Основные инструментальные средства’, не предпо- 
лагайте, а доказывайте. 

Люди на всех уровнях оперируют в своем уме многими предположениями, 
но эти предположения редко документируются и зачастую вызывают споры у 
разных разработчиков. Предположения, не основывающиеся на точно установ- 
ленных фактах, являются бедой любых проектов. 


? См. раздел “Тема 50. Кокосами не обойтись” в главе 9, “Прагматичные проекты”. 
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КАК ПРОГРАММИРОВАТЬ ОБДУМАННО 


Всем нам хотелось бы уделять меньше времени исправлению кода, выявляя и 
устраняя ошибки на как можно более ранней стадии разработки, а также внося 
в код как можно меньше ошибок. Этого можно добиться, программируя обду- 
манно, следуя приведенным ниже рекомендациям. 


$ 


Старайтесь всегда понимать, что вы делаете. Упоминавшийся ранее Фред 
медленно пустил дело на самотек до тех пор, пока не ошпарился как ля- 
гушка, о которой речь шла в разделе “Тема 4. Суп из камней и вареные 
лягушки” главы 1 “Философия прагматизма”. 


Сможете ли вы подробно объяснить код менее опытному программисту: 
Если вам это не удается, значит вы, вероятнее всего, полагаетесь на сов- 
падения. 


Не программируйте в темноте. Стоит вам написать приложение, в котором 
вы сами не разобрались до последней буквы, или воспользоваться техно- 
логией, которую не полностью понимаете, как вы тотчас будете ужалены 
совпадениями. И если вы не знаете причин, по которым программа рабо- 
тает, — значит, вы не знаете причин, по которым она может отказать. 


Действуйте на основе плана, будь то составленного в вашем уме, начертан- 
ного на салфетке или написанного на доске. 


Полагайтесь только на надежные факты, а не на предположения. Если вы 
не знаете, надежно ли что-нибудь, — допустите самое худшее. 


Документируйте свои предположения. Материал раздела “Тема 23. Проек- 
тирование по контракту” главы 4 “Прагматичная паранойя” поможет вам 
как самому прояснить свои предположения, так и поделиться ими с дру- 
ГИМи. 


Не ограничивайтесь только тестированием своего кода, тестируйте и свои 
предположения. Не гадайте — испытайте их. Напишите утверждение для 
проверки своих предположений (см. раздел “Тема 25. Утвердительное про- 
граммирование” главы 4 “Прагматичная паранойя”). Если ваше утверж- 
дение окажется верным, значит, вы улучшили документирование своего 
кода. А если оно окажется неверным, то можете считать себя везунчиком. 


Расставьте приоритеты в своей работе. Уделите время самым важным ее 
аспектам. Более чем вероятно, что эти аспекты окажутся и самыми труд- 
ными. В отсутствие прочных и верных основ или инфраструктуры любые 
излишества неуместны. 


Не привязывайтесь к истории, позволяя существующему коду диктовать 
условия будущему коду. Можно заменить весь код, если он больше не го- 
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дится. И даже в одной программе не позволяйте тому, что уже сделано, 
накладывать ограничения на то, что предстоит сделать. Будьте готовы к 
рефакторингу кода (см. далее раздел “Тема 40. Рефакторинг”). Такое ре- 
шение может повлиять на календарный план работы над проектом. При 
этом предполагается, что принятие этого решения приведет к меньшим 
затратам, чем его не принятие". 


Таким образом, в следующий раз, когда что-нибудь покажется вам работос- 
пособным, но вы не знаете, почему — непременно убедитесь, что это не просто 
совпадение. 


Другие разделы, связанные с данной темой 


• Тема 4. Суп из камней и вареные лягушки, глава 1 “Философия прагма- 
» 
тизма". 


е Тема 9. ОКҮ — пороки дублирования, глава 2 “Прагматичный подход”. 


ә Тема 23. Проектирование по контракту, глава 4 “Прагматичная пара- 
нойя”. 

» Тема 34. Общее состояние — неверное состояние, глава 6 “Параллель- 
ность”. 


® Тема 43. Будьте осторожны. 


Упражнения 


25. Допустим, данные предоставлены поставщиком в виде массива кортежей, со- 
стоящих из пар “ключ-значение”. В частности, для ключа рероѕіїАссоопі 
значение содержит символьную строку с номером счета, как показано 
ниже. 


[ 


{: рероѕісАссоџпі, "564-904-143-00"} 


офф 


Такая структура данных показала себя идеально при проверке, проведен- 
ной на компьютерах разработчиков с 4-ядерными процессорами, а также 
на сборочной машине с 12-ядерным процессором. Но на рабочих серверах, 
работающих в контейнерах, постоянно получаются неверные номера счетов. 
Что происходит? 


Е Здесь можно зайти слишком далеко. Мы как-то познакомились с одним разработчиком, 
переписавшим весь переданный ему исходный код только потому, что у него были свои 
соглашения по именованию. 
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26. Допустим, требуется запрограммировать автоматический номеронабиратель 
для голосовых предупреждений и вести базу данных контактной информа- 
ции. По спецификации Международного союза электросвязи (ГТО) телефон- 
ные номера не могут быть длиннее 15 цифр, так что вы сохраняете номер 
телефона в числовом поле, гарантированно хранящем как минимум 15 цифр. 
Данное устройство было тщательно испытано на всей территории Северной 
Америки, и все было нормально... но неожиданно из других частей света 
устремился поток жалоб. Почему так произошло? 


27. Допустим, вы написали приложение, которое масштабируется для ресторана 
круизного судна на 5000 посадочных мест. Вы получаете жалобы на то, что 
преобразования неточны. Вы проверяете прикладной код, в котором приме- 
няется формула преобразования 16 чашек в галлон. Правильно это или нет? 


АА МИЛИ МОУ МИА ое а д А цех 


БЫСТРОДЕЙСТВИЕ АЛГОРИТМОВ 


В разделе “Тема 15. Оценивание” главы 2 “Прагматичный подход” речь шла о 
том, как оценить, сколько времени отнимет прогулка по городу или завершение 
проекта. Но имеется и другая разновидность оценок, которой программисты- 
прагматики пользуются ежедневно. Речь идет об оценке таких используемых 
в алгоритмах ресурсов, как, например, время, процессор, оперативная память 
И Т.Д. 

Такого рода оценка нередко имеет решающее значение. Так, если имеются два 
способа сделать что-нибудь, то какой из них лучше выбрать? Известно, за какое 
время программа обрабатывает 1000 записей, но если ее нужно масштабировать 
до 1000000 записей? Какие ее части при этом необходимо оптимизировать? 

Оказывается, что на все эти вопросы можно ответить, призвав на помощь 
здравый смысл, произведя некоторый анализ и воспользовавшись способом за- 
писи аппроксимаций, именуемых асимитотическим обозначением, или обозна- 
чением “О большое”. 


Что ПОДРАЗУМЕВАЕТСЯ ПОД ОЦЕНКОЙ АЛГОРИТМОВ 


В большинстве нетривиальных алгоритмов обрабатываются переменные 
входные данные некоторого рода; например, сортируются и символьных строк, 
преобразуется матрица тхи или сообщение расшифровывается с помощью 
п-разрядного ключа. Как правило, объем входных данных оказывает влияние на 
работу алгоритма: чем больше этот объем, тем дольше обрабатываются данные 
и больше оперативной памяти для этого требуется. 

Если бы такое соотношение всегда было линейным (т.е. чтобы время уве- 
личивалось прямо пропорционально величине п), то этот раздел не стоило бы 
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даже писать. Но большинство важных алгоритмов не линейны. Хорошая но- 
вость — среди них имеется немало сублинейных алгоритмов. Например, алго- 
ритму бинарного поиска не требуется просматривать все элементы для обна- 
ружения нужного. Плохая новость в том, что другие алгоритмы значительно 
уступают в быстродействии линейным алгоритмам, поскольку время их выпол- 
нения и требования к оперативной памяти возрастают быстрее, чем и. Такой 
алгоритм, которому для обработки десяти элементов требуется минута, может 
потребовать целой жизни для обработки ста элементов. 

Всякий раз, когда мы пишем какой-нибудь код, содержащий циклы или ре- 
курсивные вызовы функций, мы неосознанно проверяем требования ко време- 
ни выполнения и оперативной памяти. Такой процесс редко носит формальный 
характер и скорее служит для быстрого подтверждения правильности того, что 
мы делаем в определенных обстоятельствах. Но иногда нам все же приходится 
выполнять более подробный анализ. Именно тогда и приходит на помощь асим- 
птотическое обозначение. 


Асимптотичедскоеое ОБОЗНАЧЕНИЕ 


Асимптотическое обозначение, записываемое как О(), является математичес- 
ким средством обращения с аппроксимациями. Так, если сортировка и записей 
в конкретной подпрограмме отнимает время О(и?), такое обозначение означает, 
что в худшем случае время сортировки записей будет изменять как квадрат и. 
Стоит удвоить количество записей, как время их сортировки увеличится при- 
близительно в четыре раза. Обозначение О, по существу, означает “около...” или 
“порядка... 

Асимптотическое обозначение О() устанавливает верхний предел измеряе- 
мой величины (времени, объема оперативной памяти и т.д.). Так, если говорят, 
что для выполнения функции требуется время О(и?), то известно, что верхний 
предел времени ее выполнения не будет расти быстрее, чем и?. Иногда прихо- 
дится иметь дело с довольно сложными функциями О(), но поскольку по мере 
увеличения и преобладает член высшего порядка, то обычно удаляются все чле- 
ны низкого порядка, а также все постоянные множители, как показано ниже. 


2 2 
п н 
О Ык представляет собой то же, что и О > |, и то же, что и О(и?). 


Таково свойство асимптотического обозначения О() — один алгоритм О(и?) 
может действовать в 1000 раз быстрее, чем другой алгоритм О(и?), но это никак 
нельзя узнать из самого асимптотического обозначения. Конкретные числовые 
значения времени, объема оперативной памяти или иных величин из асимпто- 
тического обозначения получить нельзя. Оно просто показывает, каким обра- 
зом эти величины будут изменяться по мере изменения входных данных. 


254 Глава 7 = По ходу кодирования 


На рис. 7.1 показано несколько типичных асимптотических обозначений О() 
наряду с графиком для сравнения времени выполнения алгоритмов каждой ка- 
тегории. Очевидно, что алгоритм выходит из повиновения, как только преодо- 
левается предел О(и?). 
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Рис. 7.1. Время выполнения различных алгоритмов 


Допустим, имеется подпрограмма, которой требуется одна секунда для об- 
работки 100 записей. Сколько времени отнимет обработка 1000 записей? Если 
имеется алгоритм О(1), то для этой цели потребуется одна секунда. Если же 
это алгоритм О(2п), то ждать, вероятно, придется около трех секунд. Алгоритм 
О(п) покажет линейное увеличение времени обработки до десяти секунд, тог- 
да как алгоритм О(п]ёп) — до 33 секунд. Если же неудачно выбрать алгоритм 
О(и?), то окончания обработки придется ждать уже 100 секунд. А если восполь- 
зоваться алгоритмом 0(2"), то можно смело сделать перерыв на чашку чая или 
кофе, поскольку обработка должна завершиться приблизительно через 102% лет, 
и мы узнаем, каким окажется конец существования вселенной. 

Асимптотическое обозначение О() применяется не только ко времени. С его 
помощью можно представить любые ресурсы, используемые в алгоритме. На- 
пример, зачастую оказывается полезно смоделировать потребление оперативной 
памяти (см., например, упражнения в конце этого раздела). 
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Ниже перечислены типичные алгоритмы и их асимптотическое обозначе- 


ние. 


О(1) Постоянная зависимость (доступ к элементу массива, простые опе- 


раторы) 


Оп) Логарифмическая зависимость (бинарный поиск). Основание лога- 


рифма значения не имеет, поэтому данная запись равнозначна за- 
писи О(1ор, п) или О(Іа и) 


О(и) Линейная зависимость (последовательный поиск) 


О(п1е п) Линарифмическая зависимость — хуже, чем линейная, но не намно- 


го (среднее время выполнения быстрой или пирамидальной сорти- 
ровки) 


О(и) Квадратичная зависимость (сортировка методом выборки или 


вставки) 


О(и?) Кубическая зависимость (перемножение двух матриц ихи) 


О(С”") Экспоненциальная зависимость (задача коммивояжера, разбиение 


множества) 


РАЗУМНОЕ ОЦЕНИВАНИЕ АЛГОРИТМОВ 


Многие простые алгоритмы можно оценить, руководствуясь здравым смыс- 
лом, как поясняется ниже. 


® Простые циклы. Если простой цикл выполняется от 1 до и, то ему, вероят- 


нее всего, соответствует алгоритм О(п), где время увеличивается линейно 
по мере увеличения и. Характерными тому примерами служат исчерпыва- 
ющий поиск, нахождение максимального значения в массиве и вычисление 
контрольных сумм. 


Вложенные циклы. Если один цикл вложен в другой, то ему соответствует 
алгоритм О(тхи), где т и и — два предела выполнения циклов. Это обыч- 
но происходит в таких простых алгоритмах сортировки, как, например, 
пузырьковым методом, где во внешнем цикле каждый элемент массива 
просматривается по очереди, а во внутреннем цикле обнаруживается мес- 
то, где следует разместить данный элемент в отсортированном результате. 
Такие алгоритмы сортировки обычно являются алгоритмами О(и?). 


Бинарный поиск делением пополам. Если алгоритм на каждом шаге делит 
множество элементов пополам, то он, вероятнее всего, имеет логарифми- 
ческое время выполнения О(]р и). Ту же сложность имеет бинарный поиск 
в отсортированном списке, обход бинарного дерева и обнаружение перво- 
го установленного бита в машинном слове. 
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е Декомпозиция. Алгоритмы, сначала разделяющие входные данные на две 
независимые половины, обрабатывающие их по отдельности, а затем объ- 
единяющие результат, обычно являются алгоритмами О(п]п). Классичес- 
ким примером служит быстрая сортировка, разделяющая данные на две 
половины и рекурсивно сортирующая каждую из них. И хотя формально 
это алгоритм О(и?), поскольку в наихудшем случае, когда на вход посту- 
пают отсортированные входные данные, его работа сильно замедляется, 
среднее время быстрой сортировки все же составляет О(п] пи). 


е Перестановка. Всякий раз, когда в алгоритмах начинается анализ пере- 
становок элементов, время их выполнения может выйти из-под контро- 
ля. Объясняется это тем, что в перестановках задействованы факториалы 
(например, 5!=5х4х3х2х1=120 перестановок цифр от 1 до 5). Для пере- 
становки шести элементов по сравнению с пятью потребуется в шесть раз 
больше времени, а для перестановки семи элементов — в 42 раза. Харак- 
терными примерами применения алгоритмов перестановки служат такие 
признанные трудно разрешимыми задачи, как задача коммивояжера, оп- 
тимальная упаковка товаров в контейнер, разбиение множества чисел та- 
ким образом, чтобы получить одинаковую сумму в каждом подмножестве, 
и т.д. Нередко для сокращения времени выполнения подобных алгоритмов 
в конкретной предметной области применяется эвристический анализ. 


БыстрОДЕЙСТВИЕ АЛГОРИТМА НА ПРАКТИКЕ 


Вы вряд ли будете тратить много времени на то, чтобы писать подпрограм- 
мы сортировки. Доступные в библиотеках подпрограммы, вероятно, превзойдут 
все, что вы могли бы написать без существенных усилий. Тем не менее время от 
времени приходится встречаться с описанными выше типами алгоритмов. Вся- 
кий раз, когда вам приходится писать простой цикл, знайте, что вы имеете дело 
с алгоритмом О(и). Если же этот цикл содержит внутренний цикл, значит, перед 
вами алгоритм О(тхи). И тогда вы должны задаться вопросом: насколько круп- 
ными могут оказаться массивы сортируемых значений? Если они ограничены, 
то можно оценить, сколько времени потребуется для выполнения сортирующе- 
го кода. Но если размеры зависят от внешних факторов (например, количества 
записей для пакетной обработки ночью или количества имен в списке людей), 
то вам, возможно, придется остановиться и рассмотреть влияние, которое боль- 
шие входные данные могут оказать на время выполнения программы или объем 
потребляемой ею оперативной памяти. 


Оценивайте порядок производительности своих алгоритмов 
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Имеется ряд подходов, которые можно предпринять для разрешения по- 
тенциальных затруднений. Так, если у вас имеется алгоритм О(и?), попытай- 
тесь воспользоваться подходом “разделяй и властвуй’, чтобы найти алгоритм 
О(т п). 

Если вы не знаете, как долго будет выполняться ваш код или сколько опера- 
тивной памяти ему потребуется, попробуйте сначала выполнить его для неболь- 
ших количеств входных данных (того, что, вероятнее всего, оказывает влияние 
на время выполнения), а затем нанесите полученные результаты на график. По 
виду кривой этого графика вы сможете сразу же судить о зависимости времени 
выполнения от размера входных данных. Для того чтобы увидеть, изгибается ли 
кривая графика вверх, выпрямляется в линию или сглаживается по мере увели- 
чения объема входных данных, обычно достаточно получить три-четыре точки. 

Обратите также внимание на то, что вы делаете в самом коде. Простой цикл 
алгоритма О(п?) может проявить себя лучше, чем сложный цикл алгоритма 
О(п п) при малых значениях п, особенно если в цикле алгоритма О(п1еи) име- 
ется дорогостоящий внутренний цикл. 

Не забудьте и о том, что имеются и практические соображения. Так, при не- 
больших массивах входных данных время выполнения может возрастать линей- 
но. Но стоит подать на вход миллионы записей, как время выполнения кода 
резко возрастет, а производительность системы — упадет. Если вы проверяете 
подпрограмму сортировки со случайными входными данными, вас может уди- 
вить ее поведение, когда она столкнется с упорядоченными входными данны- 
ми. Постарайтесь учесть как теоретические, так и практические соображения. 
В конечном итоге имеет значение лишь проверка быстродействия вашего кода 
в реальной производственной среде, с реальными входными данными. Это при- 
водит к следующему совету: 


Проверяйте свои оценки 


Если трудно получить точные временные характеристики, воспользуйтесь 
профайлерами кода, чтобы подсчитать, сколько раз в вашем алгоритме выпол- 
няются разные действия, а затем нанесите полученные данные на график зави- 
симости от размера входных данных. 


Лучшее не всегда лучшее 


Прагматиком необходимо быть и при выборе подходящего алгоритма, пос- 
кольку самый быстродействующий алгоритм далеко не всегда оказывается на- 
илучшим для решения конкретной задачи. Так, если имеется небольшой массив 
входных данных, простая их сортировка методом вставки проявит себя луч- 
ше, чем быстрая сортировка, не говоря уже том, что для написания и отладки 
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реализующего ее кода потребуется меньше времени. Необходимо также прояв- 
лять осмотрительность, если выбираемый алгоритм требует больших затрат на 
настройку. При небольших массивах входных данных такая настройка может 
нивелировать все преимущества во времени выполнения и сделать алгоритм 
непригодным с практической точки зрения. 

Кроме того, отнеситесь осторожно к преждевременной оптимизации. Всег- 
да рекомендуется убедиться, что выбранный алгоритм является узким местом 
производительности, прежде чем тратить драгоценное время на его усовершенс- 
твование. 


Другие разделы, связанные с данной темой 


® Тема 15. Оценивание, глава 2 “Прагматичный подход”. 


Задачи 


® Каждый разработчик должен знать, каким образом алгоритмы устроены 
и как они анализируются. На эту тему Роберт Седжвик (КоБегї Ѕейреміск) 
написал целый ряд книг, в том числе Аюогийт$ [5У11] и Ая Іпітойисііоп іо 
ће Апауѕіѕ о] Авотийт5$ [$Е13]. Рекомендуем вам пополнить этими книга- 
ми свою библиотеку и взять себе за правило читать их регулярно. 


ә Тем, кто интересуется большими подробностями, чем в книгах Роберта 
Седжвика, рекомендуются перечисленные ниже книги из каноничного 
издания Аг? оў Сотршег Рговтаттіпе?, где анализируется обширный ряд 
алгоритмов. 


— Тре Ам оў Сотршет Ргостаттіпу, Уомте 1: Еипйатепіа1 АІсотїћтѕ [Ктпи98] 


— Тһе Ат оў Сотриѓет Ртовтаттіпе, Уоште 2: $етіпитетіса! АІсотііћтѕ 
[Кпи98ај] 


~ Тре Аті оў Сотршет Ргортаттіпо, Уомте 3: Ѕотііпе апа Ѕеатсһіпе [Кпи98Ы] 


— Тһе Ат оў Сотршет Ртовтаттіпе, Уоште 4А: Сотђіпаіотіаї АІротііћтз, 
РагЕ 1 [Кпи11]. 


ә Приведенное ниже упражнение 28 посвящено сортировке массивов длин- 
ных целых чисел. Какое влияние на их сортировку окажет повышение 
сложности ключей и дополнительных издержек на их сравнение? Оказы- 
вает ли структура ключей воздействие на эффективность алгоритма сор- 
тировки или же самая быстрая сортировка таковой всегда и остается: 


> Имеется русский перевод этих книг под названием Искусство программирования, выпу- 
щенный ИД “Вильямс”. — Примеч. пер. 
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Упражнения 


28. Мы запрограммировали ряд простых алгоритмов сортировки на языке Виз. 
Выполните их на разных доступных вам машинах. Будут ли полученные вами 
данные соответствовать предполагаемым кривым зависимостей? Какой вы- 
вод можно сделать об относительном быстродействии алгоритмов на отде- 
льных машинах? Каковы последствия оптимизации различных параметров 
настройки компилятора: 


29. Ранее в разделе “Разумное оценивание алгоритмов” было сказано, что би- 
нарный поиск делением пополам относится к категории алгоритмов О(]5 п). 


Можете ли вы это доказать? 


4 


30. Ранее в разделе “Асимптотическое обозначение” было сказано, что асимпто- 
тические обозначения О(ш и) и О(1о8,и) означают одну и ту же сложность 
алгоритма. Можете ли вы пояснить причину? 


АА и ел Ган иле МАЕ Ту Л ст ое ЗАЛЕ, 9 МАМААОФ ине сю Чи че КТАН уа АТТАМ А роутери тА 2 САУ УИ Та Салу ЗМ ЛИХИЕ МУЗЕИ А ВО АМАМ МАИ МУО Ме Яд РВ деть ау ен у нА СААН 


РЕФАКТОРИНГ 


“Перемена и упадок во всем, что я вижу... 
Х.Ф. Лит’, АЫйе У/йв Ме (Пребудь со мной) 


> 


По мере развития программы возникает потребность переосмыслить прежние 
решения и переделать отдельные части исходного кода. Это совершенно естест- 
венный процесс. Ведь код должен развиваться, он не является статическим. 

К сожалению, самой распространенной метафорой для разработки програм- 
много обеспечения является построение здания. В своем классическом труде 
ОБес!-Опеще4 Ѕоўмаге Сопѕітисііоп [Меу97] Бертран Мейер (Вегігапа Меуег) 
употребляет термин “построение программного обеспечения”, а скромным 
авторам данной книги приходилось даже редактировать колонку “Ѕоймаге 
Сопѕігисіоп” (Построение программного обеспечения) в журнале ІЕЕЕ Зойнуаге 
в начале 2000-х годов?. 

Строительство в качестве руководящей метафоры подразумевает выполнение 
следующих действий. 


1. Архитектор чертит чертежи. 


2. Подрядчики углубляют фундамент, возводят стены, проводят канализа- 
цию и прочие коммуникации и выполняют отделочные работы. 


6 См. по адресу ВЕфр5: / /теаіа-огідіп.ргадргод. сом/{1&1ез/&рр20/соае/ 
аїдогіёһт зрееЯ9/зогЕ/зхгс/ма1п.г$. 


7 “ ы 
Н. Е Гуе — шотландский англиканский пастор, теолог, поэт ХІХ века, а также автор цер- 
ковных гимнов. — Примеч. пер. 


5 И мы, конечно, выражали свою озабоченность по поводу названия этой колонки. 
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3. Жильцы заселяют дом и счастливо живут в нем, периодически вызывая 
для устранения неполадок эксплуатирующий здание персонал — электри- 
ков, сантехников и др. 


Безусловно, программное обеспечение таким способом не разрабатывается. 
Его разработку можно сравнить не со стройкой, а скорее с выращиванием, пос- 
кольку оно более органичное, а не бетонное. Растения высаживаются в саду по 
заранее составленному плану и в соответствии с местными условиями. Одни 
растения успешно вырастают, а другие в конечном итоге идут на компост. Рас- 
тения можно пересаживать, чтобы выгодно воспользоваться взаимным влияни- 
ем света и тени, ветра и дождя. Слишком заросшие растения обрезаются, а те, 
что не ласкают взгляд, переносятся в эстетически более привлекательное место. 
Кроме того, выпалываются сорняки и удобряются те растения, которые требуют 
дополнительного ухода. Здоровое состояние сада требует постоянного контроля 
и ухода по мере надобности за почвой, растениями и их размещением. 

Для деловых людей более удобной метафорой является построение здания, 
поскольку оно более научно, чем садоводство, повторяемо, ему присуща жесткая 
иерархия отчетности перед руководством и т.д. Но ведь мы строим не небоскре- 
бы и не ограничены в своих действиях пределами физики и реального мира. 

Метафора садоводства намного ближе к реальностям разработки програм- 
много обеспечения. Так, одна подпрограмма может слишком разрастись, а по- 
пытка реализовать слишком крупное функциональное средство может потребо- 
вать его разделения. Все, что не работает нормально, необходимо искоренить, 
выполоть или обрезать. 

Переписывание, переработка и переделка архитектуры кода сообща называ- 
ется реструктуризацией. Рефакторинг представляет собой практическое под- 
множество такой деятельности. 

В своей книге Кејлсіогіпе: Гтртоутя ће Юеѕірп о} Ехіѕііпе Сойе? [Еом19] Мар- 
тин Фаулер (Магііп Еоуег) определяет рефакторинг следующим образом: 


“дисциплинированная методика перестройки структуры существующего 
тела кода, изменение его внутренней структуры без изменения его внешне- 
го поведения” 


Самые важные части этого определения таковы. 


1. Деятельность дисциплинирована, а не хаотична. 


2. Внешнее поведение не меняется, а следовательно, при этом не вводятся 
новые функциональные средства. 


7 Имеется русский перевод: Мартин Фаулер, Кент Бек, Джон Брант, Уильям Опдайк, Дон 
Робертс. Рефакторинг: улучшение проекта существующего кода. — СПб.: “Диалектика”, 
2017. 
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Рефакторинг не предусмотрен как особый церемониальный вид деятельнос- 
ти, выполняемый лишь изредка, подобно запашке всего сада для пересадки рас- 
тений. Напротив, рефакторинг представляет собой повседневную деятельность, 
выполняемую мелкими шажками с малым риском что-то испортить, подобно 
прополке или поливанию. Вместо глобального переписывания кода применя- 
ется точно нацеленный, выверенный подход, помогающий упростить внесение 
изменений в код. 

Чтобы гарантировать неизменяемость внешнего поведения, требуется качес- 
твенное, автоматизированное модульное тестирование, проверяющее правиль- 
ность поведения кода. 


Когда СЛЕДУЕТ ВЫПОЛНЯТЬ РЕФАКТОРИНГ 


Рефакторинг выполняется, когда вы что-то изучили, когда понимаете что-то 
лучше, чем в прошлом году, вчера или еще десять минут назад. 

Вполне возможно, что вы наткнулись на камень преткновения, поскольку 
код уже не вполне отвечает исходным требованиям; а может быть, заметили, 
что два компонента следует непременно объединить, или обратили внимание 
на еще что-нибудь такое, что поражает вас, как “неверное”. В таком случае не 
колеблясь, измените код. Сделать это лучше всего сразу же, не откладывая на 
будущее. Вот только некоторые из причин для рефакторинга кода. 


• Дублирование. Обнаружено нарушение принципа ОКУ. 


» Неортогональный дизайн. Обнаружено нечто такое, что можно сделать 
более ортогональным. 


• Устаревшие знания. Изменились обстоятельства, сменились требования, 
ваше знание решаемой задачи расширилось. В таком случае код необхо- 
димо сделать актуальным, приведя его в соответствие с произошедшими 
изменениями. 


• Применение. По мере того как система эксплуатируется реальными людьми 
в реальных условиях, приходит понимание того, что некоторые функцио- 
нальные средства теперь больше важны, чем предполагалось ранее, тогда 
как “обязательные” прежде средства таковыми, вероятно, уже не являются. 


® Производительность. Возникла потребность перенести функциональные 
возможности из одного участка системы в другой, чтобы повысить общую 
производительность. 


® Прохождение тестов. Да, именно так. Ведь ранее говорилось, что рефак- 
торинг должен быть мелкомасштабным видом деятельности, и поэтому 
он должен поддерживаться грамотно написанными тестами. Так, когда вы 
добавляете некоторый код, который проходит еще один дополнительный 
тест, у вас появляется отличная возможность углубиться в код и привести 
в порядок то, что вы только что написали. 
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Рефакторинг — перемещение функциональных возможностей и обновле- 
ние прежних решений — на самом деле оказывается управлением болью. Будем 
откровенны, внесение изменений в исходный код может оказаться довольно 
болезненным. Раньше код работал нормально, так что его хочется оставить в 
покое. Многие разработчики неохотно снова возвращаются к фрагменту кода 
лишь потому, что он не полностью правильный. 


Сложности реального мира 


Итак, вы обращаетесь к коллегам по работе или клиенту и заявляете: “Этот 
код вполне работоспособен, но мне потребуется неделя, чтобы выполнить его 
рефакторинг”. Из этических соображений мы не приводим их (непечатный) 
ответ. 

Нехватка времени нередко служит оправданием отказа от рефакторинга. Но 
это оправдание не выдерживает никакой критики. Если не выполнить рефак- 
торинг кода сейчас, то для устранения неполадок позже потребуется затратить 
намного больше времени. И чем дальше, тем с большим количеством зависи- 
мостей придется считаться. Будет ли у вас столько времени вообще? Вряд ли. 

Этот принцип, возможно, придется объяснить другим, используя медицин- 
скую аналогию, рассматривая код, требующий реализации, как “нарост”. Что- 
бы удалить его, потребуется хирургическое вмешательство. Это можно сделать 
сразу, удалив нарост, пока он еще невелик. Можно подождать до тех пор, пока 
нарост не станет больше и не распространится дальше, но его удаление впос- 
ледствии может обойтись дороже и быть опаснее. Стоит подождать еще немно- 
го, и можно вообще потерять пациента. 


Выполняйте рефакторинг кода как можно раньше и чаще 


Столь же опасно со временем может разрастить и ущерб коду (см. раздел 
“Тема 3. Программная энтропия” главы 1 “Философия прагматизма”). Как и 
большинство других методик, рефакторинг проще выполнить, пока трудности 
невелики, как просто разновидность деятельности во время программирова- 
ния. Для рефакторинга фрагмента кода не требуется неделя, в течение которой 
можно было бы полностью переписать код. Если уж необходим именно такой 
перерыв в основной работе — вы можете не иметь возможности приступить 
к исправлениям немедленно. В таком случае следует уведомить пользователей, 
что на некоторый конкретный срок запланирована переделка кода, а также по- 
яснить, как это может повлиять на их работу. 
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Порядок ВЫПОЛНЕНИЯ РЕФАКТОРИНГА 


Первыми рефакторингами кода начали заниматься программисты на языке 
Зта[КаК. Когда мы писали первое издание этой книги, данная методика начала 
приобретать все больше приверженцев, возможно, благодаря посвященной этой 
теме книге Ќејасіогіпр: ГПтргоутя Ше РЮеѕірп ој ЕхНния Соае [Еом19] (у которой 
недавно вышло второе издание!?). 

Рефакторинг, по существу, является его перепроектированием. Все, что проек- 
тируете вы и ваши коллеги, может быть перепроектировано в свете новых фак- 
тов, более глубокого понимания, изменения требований и т.д. Но если вы станете 
с неистовым рвением бросаться кромсать огромные куски кода, то можете ока- 
заться в еще худшем положении, чем перед началом данной операции. 

Очевидно, что рефакторинг — это вид деятельности, который следует выпол- 
нять медленно, осторожно и внимательно. Мартин Фаулер предлагает следующие 
простые рекомендации относительно того, как реорганизовывать код, чтобы не 


нанести вреда больше, чем принести пользы!!. 


1. Не пытайтесь выполнять рефакторинг, попутно добавляя функциональные 
возможности. 


2. Прежде чем приступать к рефакторингу, обязательно напишите качест- 
венные тесты. Выполняйте тестирование как можно чаще. Это позволит 
вам быстро выяснить, не нарушили ли что-нибудь внесенные вами изме- 
нения. 


3. Продвигайтесь короткими, осторожными шагами: перенесите поле из од- 
ного класса в другой, разделите метод на части, переименуйте переменную. 
Рефакторинг зачастую подразумевает внесение множества мелких лока- 
лизованных изменений, приводящих в итоге к крупномасштабным пере- 
менам. Если сохранять темп продвижения мелкими шагами и выполнять 
тесты после каждого сделанного шага, то можно избежать продолжитель- 


НОЙ отладки!?. 


10 Имеется русский перевод: Мартин Фаулер. Рефакторинг кода на Јауа$стірі: улучшение 
проекта существующего кода, 2-е изд. — СПб.: “Диалектика”, 2019. 


1 Первоначально они появились в книге ИМЕ Оё5НЦеа: А Вгіеў Сиде іо те бапаата Ођјесі 
Модеііпс Гапвиаве [Еом00]. 


1 ў ? 
2 Это, в общем, превосходный совет (см. также раздел “Тема 27. Не опережайте свет фар 
вашего автомобиля” главы 4 “Прагматичная паранойя”). 
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АВТОМАТИЧЕСКИЙ РЕФАКТОРИНГ 


В первом издании этой книги отмечалось, что данная методика еще не вы- 
шла за пределы среды $та!Ка!К, хотя такое положение, вероятнее всего, 
изменится. Так оно и произошло, и теперь автоматический рефакторинг 
доступен во многих интегрированных средах разработки для большинства 
ведущих языков программирования. 


Такие интегрированные среды разработки способны автоматически пере- 
именовывать переменные и методы, разделять длинную подпрограмму на 
более мелкие составляющие, распространять необходимые изменения по 
коду, помогать переносить код с помощью перетаскивания мышью и выпол- 
нять прочие полезные действия для рефакторинга кода. 


О тестировании на данном уровне речь пойдет подробнее в разделе “Тема 41. 
Тестировать, чтобы кодировать” далее в этой главе, а о крупномасштабном тес- 
тировании — в разделе “Строгое и непрерывное тестирование” главы 9 “Прагма- 
тичные проекты”. Но рекомендация Мартина Фаулера относительно проведения 
качественных регрессионных тестов имеет решающее значение для надежного 
рефакторинга кода. 

Если приходится выходить за пределы рефакторинга кода и в конечном счете 
изменять внешнее поведение или интерфейсы, то такие действия могут привести 
к преднамеренному нарушению сборки, когда прежним клиентам данного кода 
не удастся его скомпилировать. Это позволит выяснить, что именно требуется 
обновить. И если в следующий раз вы обнаружите фрагмент кода, работающий 
не совсем так, как требуется, — исправьте его. Управляйте болью: ведь если она 
беспокоит вас теперь, то еще больше будет беспокоить в дальнейшем, так что 
лучше вылечить ее сразу и окончательно. Вспомните уроки из раздела “Тема 3. 
Программная энтропия” главы 1 “Философия прагматизма”: нельзя жить с раз- 
битыми окнами. 


Другие разделы, связанные с данной темой 


® Тема 3. Программная энтропия, глава 1 “Философия прагматизма". 
ә Тема 9. ОКУ — пороки дублирования, глава 2 “Прагматичный подход”. 
• Тема 12. Трассирующие пули, глава 2 “Прагматичный подход”. 


® Тема 27. Не опережайте свет фар вашего автомобиля, глава 4 “Прагматич- 
ная паранойя’. 


ө Тема 44. Именование. 


• Тема 48. Сущность гибкости, глава 8 “До начала проекта". 
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ТЕСТИРОВАТЬ, ЧТОБЫ КОДИРОВАТЬ 


Первое издание этой книги было написано в более простые времена, когда 
большинство разработчиков не писали тесты. Он считали, что делать это не 
стоит, поскольку все равно в 2000 году наступит конец света. В первом издании 
книги был раздел, посвященный построению кода, который легко тестировать. 
Это был хитрый способ убедить разработчиков все же писать тесты. 

Теперь же настали более просвещенные времена. Если еще и остались разра- 
ботчики, которые до сих пор не пишут тесты, то они, по крайней мере, должны 
знать, что обязаны это делать. 

Тем не менее, когда мы спрашиваем разработчиков, зачем они пишут тес- 
ты, они смотрят на нас так, как будто мы спросили, пользуются ли они до сих 
пор перфокартами, и обычно отвечают: “Чтобы убедиться в работоспособности 
кода”, хотя и не говорят вслух, что задающий такие вопросы — “чайник” в про- 
граммировании. Но мы все же считаем такой ответ неверным. 

Так что же мы считаем самым важным в тестировании и как оно должно про- 
водиться? Отвечая на эти вопросы, начнем со следующего смелого заявления: 


Тестирование предназначено не для выявления 
программных ошибок 


Мы считаем, что основные выгоды из тестирования извлекаются в том слу- 
чае, когда тесты обдумываются и пишутся, а не тогда, когда они выполняются. 


ОБДУМЫВАНИЕ ТЕСТОВ 


Представьте, что в понедельник утром вы приступаете к работе над каким-то 
новым кодом. Вам нужно написать код, запрашивающий в базе данных список 
людей, просматривающих больше 10 видеофильмов в неделю на вашем веб-сай- 
те, где размещаются “самые забавные в мире видеофильмы о мытье посуды". 

С этой целью вы запускаете свой текстовый редактор и приступаете к напи- 
санию следующей функции, выполняющей запрос: 


её геіцгп ауіа уіемегѕ ао 
# ... м-да! 
епа 


Постойте! Откуда вы знаете, что поступаете правильно? 

Ответ в том, что ни вы и никто другой не можете этого знать. Но это может 
стать более вероятным, если думать о тестах. И вот как это делается. 

Представьте сначала, что завершили написание упомянутой выше функции 
и теперь вам нужно ее проверить. Как это сделать? Ведь для этого потребуются 
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какие-то тестовые данные, а следовательно, придется обратиться к управляе- 
мой вами базе данных. В этом вам могут, конечно, помочь некоторые каркасы, 
проводящие тесты с помощью некоторой тестовой базы данных. Но в данном 
случае вы должны передать своей функции отдельный экземпляр базы данных, 
а не нечто глобальное, чтобы во время тестирования можно было внести в нее 
какие-то изменения. 


аеЁ геіогп ауіа оѕегѕ (ар) до 


Затем необходимо подумать о том, как заполнить базу тестовыми данными. 
Ведь исходно требуется получить список людей, просматривающих больше 10 
видеофильмов в неделю. Следовательно, в схеме базы данных необходимо найти 
те поля, которые могут помочь в реализации такого требования. В таблице базы 
данных действительно имеются поля орепеа уідеои сопр1ефеа у1аео, ко- 
торые могут помочь в получении искомого списка. Чтобы сформировать тесто- 
вые данные, нужно точно знать, каким полем можно воспользоваться. Но в ис- 
ходном требовании об этом ничего конкретного не сказано, а бизнес-контакты 
отсутствуют. Поэтому придется пойти на обман и, чтобы проверить функцию 
(а возможно, даже изменить ее в дальнейшем), просто передать ей имя поля. 


ЧеЁ геіџгп ауіа оѕегѕ (ар, чиа11Еу1па Ғіе1а папе) до 


Итак, мы с вами стали думать о тестах. Не написав ни строчки кода, мы уже 
сделали два открытия и воспользовались ими с целью изменить АРІ рассматри- 
ваемой здесь функции. 


КодирОВАНИЕ НА ОСНОВЕ ТЕСТОВ 


В предыдущем примере, думая о тестировании, мы сумели уменьшить связы- 
вание в своем коде, передавая разрабатываемой функции подключение к конк- 
ретной базе данных вместо того, чтобы воспользоваться ее глобальной верси- 
ей, а также повысили степень гибкости, сделав тестируемое поле параметром. 
Размышляя о написании теста для рассматриваемой здесь функции, мы сумели 
взглянуть на нее снаружи, поставив себя на место клиента, а не автора напи- 
санного кода. 


Тест — первый пользователь вашего кода 


На наш взгляд, самое главное преимущество, которое дает тестирование, за- 
ключается в том, что оно дает жизненно важную ответную реакцию, которая, по 
существу, управляет программированием. Функция или метод, тесно связанные 
с другим кодом, с трудом поддаются тестированию, поскольку при этом, пре- 
жде чем выполнять данную функцию или метод, приходится подготавливать 
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всю необходимую среду. Таким образом, делая свой код легко тестируемым, вы 
уменьшаете его связывание с другим кодом. 

Прежде чем протестировать какой-нибудь код, его необходимо понимать. На 
первый взгляд это кажется нелепым, но на самом деле всем нам приходилось 
иметь дело с фрагментами кода, основанными на не полном понимании того, 
что мы должны делать. Мы часто уверяем себя, что по ходу дела нам удастся 
прояснить ситуацию, а в дальнейшем добавить код для поддержки граничных 
условий и обработки ошибок. В итоге код получается в пять раз длиннее, чем 
следует, поскольку он наполнен условной логикой и частными случаями. Но до- 
статочно пролить тестовый свет на такой код, как дело проясняется. Если вы 
подумаете о тестировании граничных условий и их пригодности еще до того, 
как приступить к программированию, то сможете обнаружить в логике шаб- 
лоны, упрощающие создаваемую функцию. А если вы подумаете об условиях 
возникновения ошибок, которые нужно проверять, то соответственно структу- 


рируете вашу функцию. 


Разработка на основе тестирования 


В программировании существует направление, которое задается следующим 
вопросом: если все преимущества обдумывания тестов имеют такое первосте- 
пенное значение, то почему бы не писать в первую очередь именно тесты? При- 
верженцы этого направления практикуют методику, называемую разработкой 
на основе тестирования ({е{-Апуеп 4еуе]ортепе — ТОО). Иногда ее еще назы- 
вают разработкой с предварительным тестированием”. 


Ниже приведен основной цикл разработки на основе тестирования. 


1. Наметить небольшую часть функциональных возможностей, которые тре- 
буется добавить. 


2. Написать тест, который будет успешно пройден, как только будет реали- 
зована данная часть функциональных возможностей. 


3. Выполнить все тесты. Убедиться, что не проходит лишь только что напи- 
санный тест. 


4. Написать минимальный фрагмент кода, требующийся для прохождения 
данного теста, и убедиться, что теперь он благополучно проходит. 


5. Реорганизовать код, выяснив, можно ли каким-то образом усовершенство- 
вать то, что было только что написано (тест или проверяемая функция). 
По завершении убедиться, что тесты по-прежнему успешно проходят. 


я Некоторые утверждают, что разработка на основе тестирования и разработка с предва- 
рительным тестированием являются разными методиками, говоря, что у них разные цели. 
Но исторически сложилось так, что разработка с предварительным тестированием, про- 
исходящая от экстремального программирования, оказалась идентична тому, что теперь 
принято обозначать сокращением ТОО. 
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Смысл в том, что данный цикл должен быть кратким и выполняться в счи- 
танные минуты. А это означает, что тесты приходится писать постоянно и про- 
граммировать так, чтобы они в конечном итоге были успешно пройдены. На 
наш взгляд, методика ТЮР выгодна в основном тем разработчикам, которые на- 
чинают работу над своим проектом с тестирования. Если вы будете придержи- 
ваться последовательности операций по приведенной выше методике, то можно 
гарантировать, что у вас всегда будут тесты для проверки вашего кода. И это 
означает, что вы будете всегда думать о тестах. 

Нам, однако, приходилось встречать и таких людей, которые стали букваль- 
но рабами разработки на основе тестирования. Такое раболепие перед данной 
методикой проявляется по-разному. 


® Они тратят непомерно много времени, чтобы обеспечить полное покрытие 
написанного кода тестами. 


® У них накапливается много избыточных тестов. Например, прежде чем 
написать класс в первый раз, многие приверженцы разработки на основе 
тестирования, пишут тест, который просто ссылается на имя этого класса. 
Убедившись, что тест сбоит, они пишут определение пустого класса, пос- 
ле чего данный тест оказывается успешно пройденным. Но ведь этот тест 
совершенно ничего не проверяет! В очередном написанном тесте также 
делается ссылка на класс, а следовательно, предыдущий тест просто не ну- 
жен. Если в дальнейшем имя класса изменится, то в тесты придется внести 
больше изменений. А ведь это самый простой пример. 


е Их проектирование обычно начинается снизу и продвигается вверх. (См. 
далее врезку “Проектирование снизу вверх и сверху вниз. Как это следует 
делать”) 


Как бы там ни было, непременно применяйте в своей практике разработку на 
основе тестирования. Но при этом не забывайте периодически останавливаться, 
чтобы оценить общую картину. Ведь очень легко, соблазнившись сообщением 
“тест прошел” с зеленым индикатором, написать немало кода, который никак не 
приближает вас к решению поставленной задачи. 


ПРИМЕНЯЯ РАЗРАБОТКУ НА ОСНОВЕ ТЕСТИРОВАНИЯ 
НУЖНО ЗНАТЬ, КУДА ИДТИ 


В старой шутке спрашивается: “Как съесть слона?”, на что дается лаконичный 
ответ: “По частям”. Эта идея нередко превозносится как преимущество разра- 
ботки на основе тестирования. Если нельзя решить задачу целиком, ее можно 
решить по частям, предпринимая мелкие шаги, тест за тестом. Но такой подход 
может вводить в заблуждение, поощряя сосредоточиваться на простых задачах, 
бесконечно оттачивая их решение и в то же время пренебрегая главной причи- 
ной написания кода. 
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Любопытный случай, характеризующий такой подход, произошел в 2006 году, 


когда Рон Джеффрис, видный активист движения за гибкость в разработке про- 
граммного обеспечения, опубликовал целый ряд блог-постов, где он описал свой 
метод программирования решателя головоломок судоку на основе тестирования“. 
Пять блог-постов спустя он уточнил представление исходной доски для судоку, 
неоднократно выполняя реорганизацию кода до тех пор, пока его не удовлетво- 
рила объектная модель. Но затем он забросил этот проект. Любопытно прочитать 
его блог-посты по порядку, следя за тем, как этот умный человек отвлекался на 


незначительные мелочи, будучи зачарованным блеском успешных тестов. 


Еще в те времена, когда вычислительная техника была молода и беззабот- 
на, существовали два направления в проектировании: сверху вниз и снизу 
вверх. Приверженцы проектирования сверху вниз говорят, что начинать сле- 
дует с общей задачи и пытаться решить ее, разбивая на мелкие части, а те — 
на еще более мелкие части и так далее до тех пор, пока не будут достигнуты 
настолько мелкие части, что их можно выразить непосредственно в коде. 


Приверженцы проектирования снизу вверх предпочитают строить код, как 
дом. Они начинают с создания такого уровня кода, который дает им неко- 
торые абстракции, приближающие их к той задаче, которую они пытаются 
решить. Затем они вводят еще один уровень с более общими абстракция- 
ми. И так продолжают до тех пор, пока не достигнут конечного уровня с аб- 
стракцией, решающей поставленную задачу. 


Ни одна из этих методик проектирования на самом деле не годится, пос- 
кольку в обеих игнорируется одна из самых важных особенностей разработ- 
ки программного обеспечения: когда мы начинаем разработку, мы не знаем, 
что делаем. Сторонники проектирования сверху вниз считают, что они спо- 
собны изначально выразить все требование в целом, хотя это сделать не- 
льзя. А сторонники проектирования снизу вверх считают, что они способны 
составить перечень абстракций, который позволит им постепенно прийти к 
одному решению на верхнем уровне. Но как им выбрать функциональные 
возможности отдельных уровней, если они не знают, куда направляются? 


Мы твердо убеждены, что строить программное обеспечением можно толь- 
ко инкрементно. Создавайте функциональные возможности небольшими 
частями, изучая по ходу дела решаемую задачу. Применяйте приобретен- 
ные знания по мере реализации кода, на каждой стадии привлекайте заказ- 
чиков, позволяя им направлять данный процесс. 


4 См. по адресу ВЕЕрз: / /гопјеЁЁгіеѕ.соп/ саіедогіеѕ/ ѕзоаоки. Выражаем ис- 


креннюю благодарность Рону за то, что позволил нам привести здесь его историю. 
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Стройте комплексно, а не сверху вниз или снизу вверх 


В противоположность этому Питер Норвиг описывает альтернативный под- 
ход совсем иного характера”. Вместо того чтобы руководствоваться тестами, он 
начинает с уяснения, каким образом такого рода задачи решались традиционно 
с помощью распространения ограничений, а затем сосредоточивается на своем 
алгоритме. В частности, он реализует доску в десятке строк кода, которые выте- 
кают непосредственно из обсуждения обозначений, принятых в судоку. 

Тесты определенно могут помочь в разработке. Но если не иметь в виду ко- 
нечной цели, то в результате можно просто бесконечно ходить по круту. 


Возврат к КОДУ 


Компонентная разработка уже давно стала возвышенной целью проекти- 
рования программного обеспечения". Ее идея состоит в том, что обобщенные 
программные компоненты должны быть доступны и должны объединяться так 
же просто, как и большинство интегральных схем (ИС). Но такая методика при- 
годна лишь в том случае, если заранее известно, что применяемые компонен- 
ты надежны и соответствуют принятым нормам, таким как общее напряжение, 
стандарты соединений, временные характеристики и прочие параметры в про- 
изводстве ИС. 

ИС проектируются с учетом их испытаний, причем не только на заводе-из- 
готовителе или на месте их установки на печатные платы, но и в месте их экс- 
плуатации. В более сложных ИС и системах могут быть предусмотрены сред- 
ства встроенного самоконтроля (Ви -ш 5еЁ Теѕї — ВІЅТ), выполняющие внут- 
реннюю диагностику на каком-нибудь элементарном уровне, или же механизм 
тестового доступа (Тез{ Ассеѕѕ Месһапіѕт — ТАМ), предоставляющий средства 
тестирования, которые позволяют подавать на ИС заданные воздействия из 
внешней среды и собирать их ответные реакции. 

То же самое можно сделать и в программном обеспечении. Как и нашим 
коллегам, разработчикам электронного оборудования, нам нужно с самого на- 
чала встраивать тестируемость в разрабатываемое программное обеспечение 
и тщательно проверять каждый из его компонентов, прежде чем соединять их 
вместе. 


15 См. по адресу Һер: / /пог\у19 .сош/ зааока . Вим]. 


16 Такая методика была опробована еще в 1986 году, когда Кокс (Сох) и Новобильски 
(МоуобП$К1) изобрели термин “программная интегральная схема’, введя его в своей книге 
Орјесі-Отіепіеа Ргобтаттиик: Ап Еуоіиііопагу Арртоасһ [СМ№91] по языку ОБесвуе-С. 
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Модульное ТЕСТИРОВАНИЕ 


Испытание оборудования на уровне ИС приблизительно равнозначно мо- 
дульному тестированию программного обеспечения, когда каждый модуль тес- 
тируется по отдельности для проверки его поведения. Тщательно протестировав 
модуль в контролируемых (и даже искусственных) условиях, можно составить 
более ясное представление о том, как он отреагирует на окружающий мир. 

Модульный тест программного обеспечения представляет собой код, испы- 
тывающий модуль. Как правило, модульный тест сначала настраивает опреде- 
ленного рода искусственную среду, а затем вызывает подпрограммы тестируе- 
мого модуля. Далее он проверяет возвращаемые результаты, сравнивая их с из- 
вестными значениями или результатами предыдущих прогонов того же самого 
теста (регрессионное тестирование). 

В дальнейшем, когда модули собираются как “программные ИС” в готовую 
систему и есть уверенность, что отдельные ее части работают должным обра- 
зом, можно воспользоваться теми же средствами модульного тестирования для 
испытания всей системы в целом. Подробнее о такой крупномасштабной про- 
верке системы речь пойдет в разделе “Строгое и непрерывное тестирование” 
главы 9 “Прагматичные проекты”. 

Но прежде чем зайти в тестировании так далеко, необходимо решить, что 
именно следует тестировать на модульном уровне. В исторической перспективе 
программисты раньше вводили несколько произвольных битов данных в код, 
анализировали операторы вывода и называли это тестированием. Но ведь для 
тестирования кода можно сделать намного больше. 


ТЕСТИРОВАНИЕ СООТВЕТСТВИЯ КОНТРАКТУ 


Мы предпочитаем рассматривать модульное тестирование как тестирование 
соответствия контракту (см. раздел “Тема 23. Проектирование по контракту” 
главы 4 “Прагматичная паранойя”). При этом требуется написать такой тест, 
который гарантирует, что проверяемый модуль выполняет свой контракт. Такой 
тест позволит выяснить следующее: соответствует ли написанный код контрак- 
ту и отвечает ли сам контракт своему назначению. Требуется также проверить, 
предоставляет ли тестируемый модуль обещанные им функциональные возмож- 
ности в обширном ряде контрольных примеров и граничных условий. 

Что же все это означает на практике? Начнем ответ на этот вопрос с просто- 
го числового примера: функции извлечения квадратного корня. Ее документи- 
рованный контракт довольно прост: 


предусловия: 
агаотепі >= 0; 


постусловия: 
((геѕиції * геѕиії) - агадотепё) .арѕ <= ерѕі1оп*агадцтепі; 
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Это нам подсказывает, что в тесте необходимо сделать следующее. 
*з Передать отрицательный аргумент и убедиться, что он отвергается. 


е Передать нулевой аргумент и убедиться, что он принимается (это гранич- 
ное значение). 


® Передать значения в пределах от нуля до максимального выражаемого 
аргумента и убедиться, что разность результата извлечения квадратного 
корня и исходного аргумента меньше некоторой мелкой дробной части 
аргумента. 


Вооружившись этим контрактом и считая, что рассматриваемая здесь функ- 
ция извлечения квадратного корня самостоятельно проверяет свои пред- и пос- 
тусловия, можно написать тестовый сценарий, чтобы запустить его на выполне- 
ние и испытать данную функцию, как показано ниже. 

аѕѕегійіёһіпЕрѕі1оп (му заг® (0), 0) 

аѕзѕзегійіёһіпЕрѕі1Іоп (му заге (2.0), 1.4142135624) 

аѕзѕзесійіёћіпЕрѕі1оп (ту заге (64.0), 8.0) 


аѕѕзегійіёһіпЕрѕі1оп (му заге (1.0е7), 3162.2776602) 
аѕзѕегіКаізѕеѕЕхсерёіоп Ёп => пу ѕагї (-4.0) епа 


Это довольно простой пример, но на практике любой нетривиальный мо- 
дуль, вероятно, будет зависеть от целого ряда других модулей. Так как же про- 
тестировать их вместе? 

Допустим, имеется модуль А, в котором применяются модули раїёаЕееа и 
ІіпеагКедгезѕіоп. В таком случае мы должны выполнить тестирование в 
следующем порядке. 

1. Контракт модуля раёаҒееа, полностью. 
2. Контракт модуля Іі пеагКедгезѕзіоп, полностью. 


3. Контракт модуля А, который полагается на другие контракты, хотя и не 
раскрывает их непосредственно. 


Для такого рода тестирования требуется, чтобы сначала были проверены мо- 
дули, подчиненные тестируемому модулю. Как только эти подчиненные модули 
будут проверены, можно тестировать и основной модуль. 

Если тесты модулей рааҒееа и 1: пеагКедгеѕѕіоп пройдут, а тест модуля 
А не пройдет, можно с уверенностью сказать, что причина сбоя кроется в моду- 
ле А или же в применении одного из подчиненных ему модулей. Такая методика 
тестирования позволяет существенно сэкономить на отладке, поскольку дает 
возможность быстро сосредоточиться на вероятном источнике сбоя в модуле А 
и не тратить зря время на перепроверку подчиненных ему модулей. 

К чему все эти хлопоты? Прежде всего, требуется избежать создания “бомбы 
замедленного действия”, которая может оказаться заложенной в исходном коде 
и незамеченной, взорвавшись в самый неподходящий момент позже в проекте. 
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Делая акцент на тестировании соответствия контракту, мы можем попытаться из- 
бежать стольких бед по ходу дальнейшего выполнения проекта, сколько удастся. 


Проектируйте с учетом тестирования 


(СПЕЦИАЛЬНОЕ ТЕСТИРОВАНИЕ 


Тестирование называется специальным (ай Бос) при ручном дополнении в кон- 
кретном месте исходного кода. Это может быть простой вызов соп$о1е.1о4 () 
или фрагмент кода, введенный в диалоговом режиме работы отладчика, интег- 
рированной среде разработки или цикле “чтение-вычисление-вывод” (КЕРІ). 

В конце сеанса отладки такой специальный тест требуется формализовать. 
Если в коде один раз произошла неприятность — их, вероятнее всего, будет 
больше. Не отбрасывайте написанный вами специальный тест, а добавьте его в 
арсенал своих средств модульного тестирования. | 


СОЗДАНИЕ ТЕСТОВОГО ОКНА 


Даже самые лучшие наборы тестов вряд ли сумеют обнаружить все програм- 
мные ошибки. Выявить их могут некоторые особые условия эксплуатационной 
среды. 

Это означает, что как только любой компонент программного обеспечения 
будет развернут в реальных условиях его эксплуатации, его обязательно следует 
проверить с помощью потока реальных данных. В отличие от печатной платы 
или ИС, в программном обеспечении нет контрольных выводов. Тем не менее 
можно предоставить различные представления внутреннего состояния модуля, 
не прибегая к отладчику, что может быть неудобно или вообще невозможно в 
условиях промышленной эксплуатации. 

Одним из таких механизмов являются журнальные файлы, содержащие со- 
общения трассировки. Эти сообщения должны быть представлены в точном, 
последовательном формате. Возможно, их придется проанализировать автома- 
тически, чтобы выявить время обработки или логические пути, которыми пош- 
ла тестируемая программа. Неудачно или несогласованно отформатированная 
диагностическая информация содержит столько лишнего, что ее трудно читать 
и бесполезно анализировать. 

Еще одним механизмом проникновения в выполняющийся код является пос- 
ледовательность “торячих” клавиш или “магический” ОВГ. Когда нажимается 
конкретная комбинация клавиш или осуществляется доступ к веб-ресурсу по 
указанному ОВГ, появляется окно диагностического контроля с сообщениями 
о состоянии и т.д. И хотя это совсем не то, что обычно демонстрируется конеч- 
ным пользователям, подобная информация может весьма пригодиться службе 
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технической поддержки. В более общем смысле можно было бы воспользоваться 
переключателем функциональных средств, чтобы активизировать дополнитель- 
ную диагностику для отдельного пользователя или категории пользователей. 


КУЛЬТУРА ТЕСТИРОВАНИЯ 


Все программы, которые вы пишете, должны быть непременно протестиро- 
ваны, если не вами и вашей командой, то хотя бы конечными пользователями, 
поэтому вы должны тщательно планировать стадию тестирования. Достаточно 
проявить немного предусмотрительности, чтобы свести к минимуму затраты на 
сопровождение и вызовы службы технической поддержки. 

На самом деле у вас имеются лишь следующие возможности. 


® Тестировать предварительно. 
• Тестировать по ходу программирования. 


е Вообще не тестировать. 


Предварительное тестирование, включая и разработку на основе тестирования, 
вероятно, будет наилучшим вариантом выбора в большинстве случаев, посколь- 
ку оно гарантирует, что тестирование непременно произойдет. Но иногда оно 
оказывается неудобным или бесполезным, и тогда лучше выбрать тестирование 
по ходу программирования. В этом случае можно написать фрагмент кода, по- 
работать с ним, написать для него тесты, а затем перейти к следующему фраг- 
менту кода. Самый худший вариант выбора нередко называют “протестируем 
потом”. Не будем себя обманывать, поскольку это, по существу, означает “не 
тестировать вовсе”. 

Культура тестирования означает прохождение всех тестов в любое время. 
Если не обращать внимания на те тесты, которые “никогда не проходят’, то лег- 
че пренебречь всеми тестами вообще. И тогда возникнет порочный круг (см. 
раздел “Тема 3. Программная энтропия” главы 1 “Философия прагматизма”). 

Уделяйте тестовому коду такое же внимание, как и любому рабочему коду. 
Поддерживайте его развязанным, ясным и надежным. Не полагайтесь на такие 
ненадежные вещи, как, например, абсолютное положение виджетов в системе 
с СОТ, точность отметок времени в журнале регистрации событий на сервере 
или подробности описания ошибок в сообщениях (см. выше раздел “Тема 38. 
Программирование по совпадению”). Тестирование такого рода вещей приведет 
к тому, что тесты окажутся хрупкими. 


Тестируйте свои программы сами, иначе их будут тестиро- 
вать пользователи 
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Я (Дэйв) однажды заявил, что больше не собираюсь писать тесты. И сделал я 
это отчасти для того, чтобы поколебать веру тех, кто превратили тестирова- 
ние в религию, а отчасти потому, что это было в какой-то степени правдой. 


Я программирую уже 45 лет и больше 30 лет из них пишу тесты. Думать о 
тестах во время программирования уже давно вошло в мою привычку. Мне 
так удобно. Но мой внутренний голос подсказывает, что когда я начинаю 
чувствовать себя удобно, я должен заняться чем-то другим. 


В данном случае я решил на пару месяцев перестать писать тесты, чтобы 
посмотреть, как это повлияет на мой код. К моему искреннему удивлению, 
ничего особенного не произошло, поэтому я решил уделить время выясне- 
нию причин. 


На мой взгляд, все дело в том, что наибольшая польза от тестирования про- 
истекает от обдумывания тестов и их воздействия на код. И если практико- 
вать это долго, то можно научиться думать о тестах, вообще не составляя их. 
Мой код по-прежнему оставался тестируемым, он просто не тестировался. 


Но при таком подходе во внимание не принимается то обстоятельство, что 
тесты служат также средством общения с другими разработчиками. Поэто- 
му теперь я пишу тесты для кода, общего с другими разработчиками или 
опирающегося на особенности внешних зависимостей. 


Энди не советовал мне включать эту врезку в книгу. Он предостерегал, что 
мое признание может искусить неопытных разработчиков не тестировать 
свой код. Поэтому я предлагаю следующее компромиссное решение: долж- 
ны ли вы писать тесты? Да, должны. Но после такой практики в течение 30 
лет можете немного поэкспериментировать, чтобы посмотреть, что вам вы- 
годнее: писать тесты или не писать. 


Не сомневайтесь, что тестирование является неотъемлемой частью програм- 
мирования. Эту стадию процесса разработки нельзя поручать другим подразде- 
лениям. Тестирование, проектирование, написание кода — все это входит в само 
программирование. 


Другие разделы, связанные с данной темой 


• Тема 27. Не опережайте свет фар вашего автомобиля, глава 4 “Прагматич- 
ная паранойя’. 


ә Тема 51. Начальный набор инструментальных средств программиста-праг- 
матика, глава 9 “Прагматичные проекты”. 


пои ола, та С ие еаиь дот БЛ о ее Анан р Л ааа серая А 70 ско сие нина там соя ТА Чт ДӘМ ре тина АА, ПОА жие кие ор И др лк) тела СТВА ЧЕТ ЗОВИ реет? бд Лир, АЖ 
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ТЕСТИРОВАНИЕ НА ОСНОВЕ СВОЙСТВ 


“Доверяй, но проверяй”. 
Русская пословица 


Мы рекомендуем писать модульные тесты для создаваемых функций. Для 
этого следует обдумать типичные причины, которые могут вызвать осложнения, 
опираясь на знание того, что именно тестируется. 

Но здесь возникает небольшое, но потенциально важно затруднение. Если 
вы пишете код, а вместе с ним и тесты, то могут ли и там, и там быть выражены 
неверные предположения? Код проходит тесты, поскольку он делает именно то, 
что и должен делать, — исходя из того, как вы это понимаете. 

Из этого затруднения можно, в частности, выйти, поручив писать тесты и 
проверяемый код разным людям, но нам такое решение не по душе. Как пояс- 
нялось ранее в разделе “Тема 41. Тестировать, чтобы кодировать’, одно из глав- 
ных преимуществ обдумывания тестов заключается в том, что оно дает нужные 
сведения о написанном коде. Эти сведения теряются, если работа по тестирова- 
нию и программированию разделяется. Вместо этого мы отдаем предпочтение 
автоматизации тестирования на компьютере, который действует, в отличие от 
людей, непредубежденно. 


КонтрАКТЫ, ИНВАРИАНТЫ И СВОЙСТВА 


В разделе “Тема 23. Проектирование по контракту” главы 4 говорилось о том, 
что у написанного кода имеются контракты, которым он должен соответство- 
вать. Это, по существу, условия, которым должен удовлетворять код, когда ему 
подаются на обработку входные данные, а также определенные гарантии, кото- 
рые он дает относительно получаемых в нем результатов или выходных данных. 
У написанного кода имеются также инварианты, т.е. представления о какой- 
то части состояния, которые остаются истинными, когда оно проходит через 
функцию. Так, если сортируется список, то в результате данной операции в нем 
должно оказаться такое же количество элементов, как и первоначально, т.е. дли- 
на списка инвариантна. 

Как только контракты и инварианты будут составлены, а мы склонны на- 
зывать их вместе свойствами, ими можно воспользоваться для автоматизации 
тестирования. И в конечном счете такая методика называется тестированием 
на основе свойств. 


Пользуйтесь тестами на основе свойств для проверки 
правильности ваших предположений 
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В качестве искусственного примера можно написать ряд тестов для отсорти- 
рованного списка. Мы уже установили одно свойство: длина отсортированного 
списка остается такой же, как и у первоначального. Можно также утверждать, 
что ни один элемент результирующего списка не может быть больше следующе- 
го после него элемента. 

Это можно теперь выразить непосредственно в коде. В большинстве языков 
программирования имеется особого рода библиотека или каркас для поддержки 
тестирования на основе свойств. И хотя данный пример реализован на языке 
Руфоп с помощью инструментального средства Нуроѓћеѕіѕ и каркаса ру{е$, ос- 
новные принципы остаются теми же и довольно универсальными. 

Ниже приведен весь исходный код тестов на основе свойств. 


ргорёезі/зогі.ру 


Ғгот Һуроһеѕіѕ ітрогі а1уеп 
ітрогё Һуроїһеѕіѕ.ѕігаїедіеѕ аз ѕопе 


@асіуеп (зоме. 1156$ (ѕоте.іпёедегѕ ())) 

её беѕі 115 $12е іѕ іпуагіапі асгоѕѕ ѕогііпо (а 1іѕі): 
ог191па1 Іепоїһ = Іеп (а 1ізѕ+) 
а 1іѕі.зогі () 
аззеге іеп (а 1151) == ог191па1 Іепобһ 


@аіуеп (ѕоте.1іѕіѕ (ѕоте.Гёехі ())) 
её беѕі ѕогіеа геѕиії іѕ огаегеа (а 1150): 
а 1ізі.зѕогї () 
Ғог і іп гапде (1Іеп(а 11іѕі) - 1): 
аззеге а 1150[1] <= а 1151 [1 + 1] 


А вот что произойдет, если выполнить данный код: 


$ руіезі зогё.ру 
ріџадіпѕ: һуроёһеѕіѕ-4.14.0 
БОЕ ру [100%] 


Л раззеа 17-0 Обл оО 


Ничего драматического здесь вроде бы не наблюдается. Но подспудно инс- 
трументальное средство Нуроѓћеѕіѕ выполнило эти тесты сотню раз, передавая 
каждый раз другой список на сортировку. Длина этих списков будет разной, как, 
впрочем, и их содержимое. Это все равно, что состряпать 200 отдельных тестов 
с 200 произвольными списками. 


ГЕНЕРАЦИЯ ТЕСТОВЫХ ДАННЫХ 


Как и большинство библиотек для тестирования на основе свойств, Нуроћеѕіѕ 
дает описание на мини-языке тех данных, которые следует сформировать. Такой 
язык основывается на вызовах функций из модуля Вуро{Ве$1$.зЕгафед1ез, 
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у которого имеется псевдоним зоме, употребляемый только ради повышения 
удобочитаемости. 
Так, если написать следующую строку кода: 


@єіуеп (ѕзоте.іпёедегѕ ()) 


тестовая функция будет выполнена многократно и всякий раз ей будет переда- 
но иное целочисленное значение. Если же вместо этого написать приведенную 
ниже строку кода, то в конечном счете будет получен ряд четных чисел в пре- 
делах от 10 до 20. 


@оіуеп (ѕоте.іпіедегѕ (тіп уаіџе=5, тах уа1џе=10) .тар (1апраа х: х * 2)) 


Кроме того, обе упомянутые выше строки можно составить таким образом, 
чтобы получить в итоге списки натуральных чисел длиной не меньше 100 эле- 
ментов, как показано ниже. 


@аіуеп (ѕоте.11ѕїѕ (ѕоте.іпіедегѕ (міп уа1џе=1), тах ѕі2е=100)) 


Данный пример не предназначен в качестве упражнения в применении ка- 
кой-нибудь конкретной библиотеки или каркаса. Поэтому опустим здесь многие 
несущественные подробности и вместо этого рассмотрим реальный пример. 


ВЫЯВЛЕНИЕ НЕУДАЧНЫХ ДОПУЩЕНИЙ 


Итак, предположим, что разрабатывается простая система обработки заказов 
и контроля запасов, поскольку всегда есть место для их пополнения. В этой сис- 
теме моделируются уровни запасов с помощью объекта Иагерочцзе, представ- 
ляющего склад. К такому складу можно обратиться с запросом, чтобы выяснить 
наличие запасов какого-нибудь товара, изъять товары из запасов и получить 
текущие уровни запасов. 

Ниже показано, как это реализуется непосредственно в коде. 


ргорёезё/зёоск.ру 


с1азз Магероцзе: 
Чеё іпі __ (5е1Ё, ѕіоск): 
ѕе1Е.ѕіосКк = ѕЅіоскК 


ЧеЁ іп ѕіоск (ѕе1#, іёет папе): 
геёогп (ііет пате іп ѕе1Ё.ѕіоск) 
апа (ѕе1Ғ.ѕіоск [іёет пате] > 0) 


её ‘аке Егом зіоск (ѕе1Ё, іёет пате, чаапЕ1®у): 
іЁ аоапііёу <= ѕе1Ё.ѕіоск[іёет папе]: 
ѕе1Ё.ѕіоск [ііем пате] -= аџоапііёу 
е1зе: 
гаізе Ехсерііоп ("Оуегзо1а {}".Еогтаф (1%ем_папме)) 


бӢе# ѕіоск соппЕ (5е1Ё, іёем пате): 
геёогп ѕе1Ғ.ѕіоск[ііет папе] 
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А вот как выглядит элементарный модульный тест, который написан для 


проверки данного кода и который данный код успешно проходит: 


ргоріезї/зёоск.ру 


её іеѕі магеһоиѕе () : 
мһ = Магеһоцѕе ({"ѕһоеѕ": 10, "Һаїѕ": 2, "отрге11аѕ": 0}) 
аззеге «һ.іп ѕіоск ("ѕһоеѕ") 
аззеге иһ.іп ѕсоск ("Һаїѕ") 
аззег пої мП.1п збоск ("ипрге11аѕ") 


мһ.саке Ғгот ѕіоск ("ѕһоеѕ", 2) 
аззегіё иһ.іп ѕіоск ("ѕһоеѕ") 


мһ.саке Ёгот зіоск ("ћаёѕ", 2) 
аззегі пої мП.1п ѕіоск ("ћаёѕ") 


Теперь перейдем к функции, написанной для обработки запросов на заказ 
товаров со склада. Эта функция возвращает кортеж, где первым элементом яв- 
ляется признак "ок" (товар имеется) или "по ауаі1ар1е" (товар отсутству- 
ет), авторым — количество запрашиваемого товара. Для проверки данной фун- 
кции написаны также тесты, которые проходят. Исходный код самой функции 


и ее тестов приведен ниже. 


ргоріезі/зіоск.ру 


де# огаег (магеһоцѕе, 1%ет, диапбіѓу) : 
іЁҒ магеһоџѕе.іп ѕіоск (іёет): 
магеһоцѕе.баке Ёгот ѕіоск (1ёем, аџоапііѓу) 


геёоцгп ( "ок", іїет, аоапіііу ) 
е1зе: 
геёогп ( "пої ауаі1ар1іе", іёет, чаапе1®у ) 


ргоріезі/зіоск.ру 


бе беѕі огадег іп ѕіоск() : 
мһ = Иагеһоцѕе ({"ѕһоеѕ": 10, "Һаїѕ": 2, "отрге11аѕ": 0}) 
ѕіаіџѕ, іёем, аџоапёіёу = огаег (мћ, "Һаёѕ", 1) 


азѕегё ѕіаіцѕ == "оК" 
аззегЕ ііет == "Һаіѕ" 
аззеге дџапііёу == 1 


аззегё иһ. ѕіоск соцпі ("ћаїѕ") == 


ЧеЁ тез огдег пої іп ѕіоск(): 
мһ = Магеһћоцѕе ({"ѕһоеѕ": 10, "Һаіѕ": 2, "оитпрге11аѕ";: 0}) 
зсаеа$, іёет, аоапіііу = огаег (мВ, "опрге]11аѕ", 1) 


аѕззегё ѕіаіиѕ == "пої ауаі1ар1іе" 
аззегё ііеп == "опрге]1аѕ" 
аззеге дџапііёу == 1 


аѕззегё иһ.ѕіоск соцпі ("оитрге11аѕ") == 0 
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де тезЕ огдег опкпомп іїетм() : 
мһ = Магеһоиѕе ({"ѕһоеѕ": 10, "Һаїѕ";: 2, "итрге11аѕ": 0}) 
ѕіаёцѕ, іїем, ацапе1еу = огаег (мһ, "раде]1", 1) 


аѕзѕегё ѕёаёиѕ == "поі ауаі1аріе" 
аѕзѕегі ііет == "раде1" 
аѕѕзегі диапііїу == 1 


На первый взгляд все выглядит вроде бы прекрасно. Но прежде чем выпус- 
тить рассматриваемый здесь код, дополним его некоторыми тестами на основа- 
НИИ СВОЙСТВ. 

Нам, в частности, известно, что запасы на складе не могут появляться и ис- 
чезать в течение транзакции. Это означает, что если взять некоторые товары 
со склада, количество взятых товаров плюс оставшиеся на складе должно быть 
таким же, как и первоначальное их количество. Поэтому приведенный ниже 
тест выполняется с произвольно выбранными значениями от "ћаѕ" (шапки) 
до "ѕһоеѕ" (туфли) параметра ісе (товар), а также значениями от 1 до 4 па- 
раметра аџапёіёу (количество). 


ргорёезё/зіёоск.ру 


ёоіуеп (16ем = ѕоте.ѕатр1еа Егом ( ["ѕћһоеѕ", "һаёѕ"]), 
аоапііёу = ѕоте.іпёедегѕ (піп уаіџе=1, тах уаіџе=4)) 
ЧеЁ іеѕі ѕсоск 1еуе1 р145 аџоапёіёу едџа15 огідіпа1 ѕіоск 1еуе1 ( 
іёет, аџоапёіёбу) : 
ИП = Иагсеһоцѕе ({"ѕһоеѕ": 10, "Һаіѕ": 2, "опрге11аѕ": 0}) 
іпісіа1 збосК 1еуе1 = мһ.зѕіоск сооп (іёет) 


(ѕёаёцѕ, іёем, аџапііїу) = огаег (мВ, 1$ем, аџапіііу) 
1Е Ѕіаіиѕ == "ок"; 
аззегіё иһ.ѕіоск соцпі (1ёет) + аџапііёу == іпіёіа1 зѕіоск 1еуе1 


Если выполнить данный тест, то в итоге будет получен приведенный ниже 
результат. При попытке изъять три шапки со склада, где хранятся лишь две 


шапки, данный тест завершится неудачно в функции магећоџѕе.ёаке Ёгот 
зфоск (). 


$ русезе ѕёоск.ру 


ѕіоск.ру:72: 


ѕзіоск.ру:76: 
іп сеѕі ѕіоск 1еуе1 р1а$ аџоапііёу ечиа1$_ог191па1 ѕёоск 1еуе1 
(ѕїаёцѕ, іёем, ацоапёіёу) = огаег (мһћ, 1$еш, аџапіііЁу) 
ѕіоск.ру:40: іп огаег 
магеһоцџѕе.ёаке Ёгот ѕіоск (1ёет, аоапііёу) 


зе1Е = <ѕіоск.ИЙагеһоџѕе орјесі аі 0х10сЕ97сЕ8>, іёет пате = 'һаїѕ' 
аџапёіёу = 3 


ЧеЁЕ баке Ёгот ѕіоск (ѕе1Ё, 16ем пате, дцапііѓу) : 
іЁ аџоапёіёу <= зѕеїІЁ.ѕіоск [ібет пате]: 
ѕе1Ё.ѕіоск [іёет пате] -= аџоапіібу 
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е1ѕе: 
> га1зе Ехсерііоп ("Оуегзо1а {}".Ғогтаё (ісет пате)) 
Е Ехсерііоп: Оуегѕо1а Һаіѕ 


ѕіоск.ру:16: Ехсерііоп 


Ға151#Ғуіпд ехапріе: 
еѕі ѕіоск Іеуе1 р1Ічџѕ ацапіёіёу ечиа1$_ог191па] ѕіоск 1еуе1 ( 
ііет='Һаіѕ', аџоапёіёу=3) 


В ходе рассматриваемого здесь тестирования на основе свойств было обна- 
ружено ошибочное предположение: в функции іп ѕбоск () проверяется лишь 
наличие на складе хотя бы одной единицы запрашиваемого товара. А ведь нуж- 
но убедиться, что количества запрашиваемого товара на складе достаточно, что- 
бы выполнить заказ, как показано ниже. 


ргоріезі/зіоск1.ру 


4еЕ іп ѕіоск (ѕе1#, іёсет пате, аџапііѓу): 
> геЕагп (1$ет паме іп ѕе1Ё.ѕіоск) 
апа (ѕе1#Ғ.зѕіоск [ібет пате] >= аџапііїу) 


Кроме того, необходимо внести изменения в функцию огаег (), как приве- 
дено ниже. И тогда тест на основе свойств будет успешно пройден. 


ргоріезё/зіоск1.ру 


её огаег (магеһоцџѕе, іїіетм, ацап®1у): 
> 1Е иагероцз$е.1п ѕіоск (іёет, аџапіёіёу): 
магеһоџѕе.їаке Ёгот ѕіоск (іёетм, аоапііѓїу) 
геёоџгп ( "ок", 1Сет, ачапііѓу ) 
е1зе: 
геіџгп ( "пої ауаі1аріе", іёет, аоџапііёу ) 


ТЕСТЫ НА ОСНОВЕ СВОЙСТВ СПОСОБНЫ УДИВЛЯТЬ 


В предыдущем примере тест на основе свойств служил для того, чтобы про- 
верить правильность коррекции уровней запасов. И хотя этот тест обнаружил 
программную ошибку, он все же не имел никакого отношения к коррекции 
уровней запасов. Вместо этого он обнаружил программную ошибку в функции 
іп ѕіоск (). 

В этом состоит сила и слабость тестирования на основе свойств. Его сила 
состоит в том, что сначала вы устанавливаете ряд правил для формирования 
входных данных, задаете некоторые утверждения для проверки достоверности 
выходных данных, а затем просто даете ему выполняться. Вы никогда точно не 
знаете, чем все закончится. Тест может пройти. Утверждение может не выпол- 
няться. Код вообще может не суметь обработать предоставленные ему входные 
данные. 
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Слабость же заключается в том, что выяснение причины сбоя может оказать- 
ся нелегким делом. 

Если тест на основе свойств не проходит, мы рекомендуем сначала выяснить, 
какие именно параметры были переданы тестовой функции, а затем воспользо- 
ваться их значениями для составления отдельного обычного модульного теста. 
Такой тест автоматически выполняет две функции. Во-первых, он позволяет со- 
средоточиться на обнаруженной неполадке, не делая дополнительные вызовы 
в проверяемом коде с помощью каркаса для тестирования на основе свойств. 
И во-вторых, такой модульный тест действует как регрессионный. Тесты на ос- 
нове свойств формируют произвольные значения, передаваемые данному тесту, 
и поэтому нет никакой гарантии, что одни и те же значения будут использо- 
ваны при выполнении тестов в следующий раз. Наличие же модульного теста, 
заставляющего использовать одни и те же значения, гарантирует, что данная 
программная ошибка не будет пропущена тестом. 


ТЕСТЫ НА ОСНОВЕ СВОЙСТВ ПОМОГАЮТ ПРОЕКТИРОВАТЬ 


Обсуждая особенности модульного тестирования, мы отмечали как одно из 
главных его преимуществ возможность посмотреть на написанный код и его 
АРІ с точки зрения модульного теста как первого клиента. Это же можно ска- 
зать и о тестах на основе свойств, хотя и несколько иначе. Они заставляют рас- 
сматривать написанный код с точки зрения инвариантов и контрактов, т.е. ду- 
мать о том, что не должно изменяться и что должно оставаться истинным. Такое 
дополнительное осмысление оказывает волшебное воздействие на код, устраняя 
крайние случаи и выделяя функции, оставляющие данные в несогласованном 
состоянии. 

Мы полагаем, что тестирование на основе свойств дополняет модульное тес- 
тирование. Эти методики тестирования решают разные задачи, и каждая из них 
приносит свои выгоды. Если вы пока еще не пользуетесь ими, опробуйте их на 
практике. 


Другие разделы, связанные с данной темой 
® Тема 23. Проектирование по контракту, глава 4 “Прагматичная пара- 
нойя”. 
® Тема 25. Утвердительное программирование, глава 4 “Прагматичная па- 
ранойя". 


® Тема 45. Западня требований, глава 8 “До начала проекта". 


Упражнения 


31. Обратитесь снова к рассмотренному ранее примеру со складом. Имеются ли 
какие-нибудь другие свойства, которые вы могли бы протестировать? 
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32. Допустим, ваша компания поставляет машинное оборудование. Каждая ма- 
шина упакована в ящик, имеющий прямоугольную форму и разные размеры. 
Ваша задача — написать некоторый код, чтобы упаковать как можно больше 
ящиков в одном слое в кузове грузовика. Написанный вами код должен вы- 
водить список всех ящиков. Из этого списка можно определить место для 
каждого ящика в грузовике наряду с шириной и высотой этого ящика. Какие 
свойства вывода можно было бы протестировать? 


Задачи 


• Подумайте о коде, над которым вы работаете в настоящий момент. Каковы 
его свойства — контракты и инварианты? Можете ли вы воспользоваться 
каркасом для тестирования на основе свойств, чтобы проверить эти свой- 
ства автоматически? 


О ВЫ Зое ст ет то Е Ани ие чл фреона ое, нете ее тм т рот аляр че те Ра сме г м дем столе роте, 


БУДЬТЕ ОСТОРОЖНЫ 


“Хороший сосед начинается с высокого забора”. 
Роберт Фрост’, Ремонт стены (Мепӣіпу а Май) 


При обсуждении связывания кода в первом издании этой книги мы сдела- 
ли смелое и наивное заявление, что разработчикам не следует быть чрезмерно 
подозрительными, как шпионы и диссиденты, но мы оказались не правы. На 
самом деле разработчикам необходимо не терять бдительность каждый день. 

Когда мы работали над вторым изданием этой книги, ежедневные новости 
были полны историями об опустошительных взломах информационных систем, 
подвергшихся атакам злоумышленников и кибермошенничества. При этом кра- 
дутся сотни миллионов записей за один раз, наносятся миллиардные убытки, а на 
восстановление систем после атак требуются не меньшие затраты, и эти цифры 
быстро растут каждый год. В подавляющем большинстве случаев это происходит 
не потому, что атакующие злоумышленники оказались особенно смышлеными 
или даже компетентными, а потому, что разработчики проявили беспечность. 


ДРУГИЕ 90% 


Во время программирования вы неоднократно проходите путь от “это ра- 
ботает!” до “почему это не работает?”, а иногда и до “каким образом это могло 
произойти:..”'8. Добравшись до желанной вершины после стольких подъемов и 


17 ВоБег! Егоѕї — один из самых известных американских поэтов, четырехкратный лауре- 
ат Пулитцеровской премии. — Примеч. пер. 


18 См, раздел “Тема 20. Отладка” главы 2 “Прагматичный подход”. 


284 Глава 7 • По ходу кодирования 


падений, можно, вздохнув с облегчением, сказать: “Уф, наконец-то все работает!” 
и объявить, что код готов. Разумеется, он еще не готов полностью. Работа выпол- 
нена на 90%, но теперь предстоят еще другие 90%. 

Далее необходимо проанализировать код на возможные сбои и ввести их ус- 
ловия в набор тестов. При этом следует рассмотреть такие ситуации, как пере- 
дача неверных параметров, утечка или недоступность ресурсов и т.п. 

В старые добрые времена такого оценивания внутренних ошибок могло быть 
достаточно, но сейчас это лишь начало. Ведь помимо ошибок из-за внутрен- 
них причин, необходимо выяснить, каким образом внешнее действующее лицо 
могло бы намеренно вывести систему из строя. На это вы можете возразить: 
“Да никого данный код вообще не интересует, он не так важен, и вряд ли кому- 
нибудь вообще известен этот сервер...” Но окружающий мир велик и по боль- 
шей части взаимосвязан, а значит, в нем всегда найдутся изнывающие от скуки 
школьники, поощряемые государством террористы, банды преступников, кор- 
поративные шпионы или даже мстительные бывшие сотрудники, нацеленные 
взломать вашу систему. Время выживания устаревшей, давно не обновлявшейся 
системы в открытой сети измеряется минутами, если не меньше. Безвестность 
никак не защищает. 


Основные принципы ЗАЩИТЫ 


Программистам-прагматикам присуща изрядная доля здоровой подозритель- 
ности. Им хорошо известно, что любая система несовершенна и подвержена от- 
казам, и поэтому атакующие извне злоумышленные готовы проникнуть в любую 
брешь, оставленную в защите системы, чтобы вывести ее из строя. Конкретные 
среды разработки и развертывания также испытывают потребность в защите, и 
в связи с этим ниже приведен ряд основных принципов, которые следует всегда 
иметь в виду. 


1. Минимизация площади поверхности атак. 

2. Принцип наименьших привилегий. 

3. Безопасные значения настроек по умолчанию. 
4. Шифрование секретных данных. 


5. Организация регулярного обновления системы безопасности. 


Рассмотрим каждый из этих принципов защиты по отдельности. 


Минимизация площади поверхности атак 


Площадь поверхности атак на систему — это суммарное количество всех то- 
чек доступа, где атакующий злоумышленник может ввести или извлечь данные, 
а также вызвать выполнение службы. Ниже приведены характерные примеры 
направлений атак. 
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® Сложность кода. Чрезмерная сложность кода расширяет поверхность атак, 
давая больше возможностей для проявления непредвиденных побочных 
эффектов. Сложный код способен сделать такую поверхность более про- 
ницаемой для атак и открытой для заражения вирусами. И в этом случае 
чем проще и компактнее код, тем лучше. Кроме того, чем меньше кода, тем 
меньше программных ошибок и возможностей проникновения сквозь бре- 
ши в защите. Наконец, более простой, краткий и менее сложный код легче 
анализировать и находить в нем потенциальные слабости. 


® Входные данные. Никогда не доверяйте данным из внешнего источника и 
всегда подвергайте их саночистке, прежде чем передавать их на хранение 
в базу данных, воспроизводить для просмотра или обрабатывать °. Неко- 
торые языки программирования могут в этом помочь. Например, в языке 
КоБу переменные, хранящие вводимые извне данные, считаются загряз- 
ненными, что ограничивает круг операций над ними. Например, в приве- 
денном ниже фрагменте кода явно используется команда ис, выводящая 
количество символов в файле, имя которого предоставляется во время 
выполнения. 


заЕефу/+а1пе. гЬ 


рчіѕ "Епёег а Ё11е пате їо сооп: 09 


папе = деіѕ 
зузеем ("ис -с # {пате }") 


э Бесчестный пользователь мог нанести таким кодом следующий ущерб: 


Епіег а Ғі1е пате іо соопі: 
ёеѕі.ааі; хм -хЕ / 


• Но, если установить первый уровень безопасности (ЅАЕЕ), внешние дан- 
ные станут загрязненными, а это означает, что их нельзя использовать в 
опасном контексте, как показано ниже. 


заҒе+у/баіпі.гЬ 
> ЗЗАЕЕ = 1 


рчіѕ "Епфег а Е11е пате Фо соцпі: " 
папе = деѓзѕ 
зузеем ("ис -с #{пате)") 


хх зез51оп $ гиру ёаіпё.гр Епіег а Ё11е пате іо сооп: 


17 Помните нашего хорошего знакомого малыша Бобби Тэйблса (ВоБЬу ТаЫез — персона- 
жа веб-комикса, доступного по адресу һћїрѕ: / /хкса. сот/ 327)? Пока вы вспоминаете, 
зайдите на сайт по адресу ћёёрѕ: //рорру-ЕаБ1ез . сот, где перечислены способы сано- 
чистки данных, передаваемых по запросам базы данных. 


20 м 
Введите имя файла для подсчета 
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Еее Чате 

содае/ѕаЁеу/ёаіпі.рр:5:іп ѕуѕіет': 

Іпѕесиге орегаїіоп - ѕуѕіет (ЅесогііуЕггог) Егом 
соче/заЕеку/ка1пе.хЬ:5:1п тмаіп' ~~~ 2! 


• Неаутентифицированные службы. По своей природе любой пользователь 
где угодно в мире может вызывать неаутентифицированные службы, и по- 
этому запрет или ограничение доступа к таким службам сразу же создает 
возможность, по крайней мере, для атаки типа отказа в обслуживании. 
Появившееся недавно довольно большое число брешей в общедоступных 
данных было обусловлено тем, что разработчики ненамеренно размещали 
данные в неаутентифицированных, открыто доступных для чтения инфор- 
мационных хранилищах, организованных в “облаке”. 


• Выходные данные. Существует (возможно, апокрифическая) история о 
системе, которая прилежно выдавала сообщение об ошибке "Раѕѕиога 
іѕ изеа ру апоёћег иѕег" (Этот пароль используется другим пользо- 
вателем). Не разглашайте секретные данные. Убедитесь, что сообщаемые 
вами данные пригодны для авторизации данного пользователя. Обрезайте 
или скрывайте потенциально рискованные сведения, например, номер со- 
циального страхования или другие идентификационные номера. 


е Отладочная информация. Вряд ли вас обрадует появление на экране 
местного банкомата, киоска саморегистрации в аэропорту или на сбойной 
веб-странице результатов трассировки стека. Сведения, предназначенные 
для упрощения отладки, могут также упростить несанкционированное 
проникновение в систему. Поэтому убедитесь, что любое ‘тестовое окно” 
(см. выше раздел “Построение тестового окна”) и сообщение об исключе- 


нии во время выполнения защищено от любопытных глаз соглядатаев^?. 


Не усложняйте код и минимизируйте поверхности атак 


Принцип наименьших привилегий 


Еще один важный принцип состоит в использовании наименьших приви- 
легий в кратчайший период времени. Это означает, что пользователю не пре- 
доставляется наивысший уровень привилегий, например гооѓ (корневой) или 
Аатіпіѕігаіог (административный). Если же требуется столь высокий уро- 


21 Небезопасная операция в системе (ЅесигібуЕггог) из файла соде/заѓеёу/баіпё. 
ЕО аа тее 

2? Данная методика оказалась успешной на уровне микросхем процессоров, где хорошо 
известные взломы эксплуатировали отладку и средства администрирования. Как только 
машина взломана, она оказывается полностью доступной злоумышленнику. 
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вень привилегий, он предоставляется для выполнения минимального объема 
работы, а затем быстро освобождается с целью сократить риск. Появление та- 
кого принципа относится к началу 1970-х годов. 


“Всякая программа и каждый привилегированный 
пользователь системы должны работать, пользуясь 
наименьшими привилегиями, требующимися для 
выполнения конкретного задания”. 


— Джером Зальтцер (Јеғоте $аЇігет), 
журнал Соттипісайопѕ оў ће АСМ, 1974 г. 


Возьмем, например, программу 1одіп в производных от (Опіх системах. Она 
выполняется с корневыми привилегиями. Но, как только эта программа завер- 
шает аутентификацию правильно установленного пользователя, она сразу сбра- 
сывает привилегии высокого уровня до пользовательских привилегий. 

Данный принцип распространяется не только на уровни привилегий в опе- 
рационной системе. Так, если в приложении реализуются разные уровни досту- 
па (например, “администратор” и “пользователь”), следует предусмотреть более 
мелкие градации уровней доступа, где уязвимые ресурсы разделены на разные 
категории, а отдельные пользователи наделяются привилегиями только для не- 
которых из этих категорий. 

Такая методика придерживается того же принципа минимизации площади 
поверхности атак, когда пределы направлений атак сокращаются как по време- 
ни, так и по уровню привилегий. И в данном случае, действительно, соблюдает- 
ся правило “лучше меньше, да лучше”. 


Безопасные значения настроек по умолчанию 


Значения настроек по умолчанию приложения или веб-сайта для пользова- 
телей должны быть самыми безопасными. И хотя такие значения могут быть 
не особенно удобны или пригодны для пользователей, тем не менее каждому 
пользователю должна быть предоставлена возможность самостоятельно найти 
компромисс между безопасностью и удобством. 

Например, вводимый пароль по умолчанию может скрываться, когда вместо 
вводимых с клавиатуры символов на экране отображаются звездочки. Такой ре- 
жим благоразумно установить для ввода пароля в общественных людных местах 
или для демонстрации приложений в большой аудитории. Но тем категориям 
пользователей, которым требуются специальные возможности, вероятно, при- 
дется указывать вводимый пароль прописью. 


Шифрование секретных данных 


Удостоверяющие личность сведения, информация о финансовом состоянии, 
пароли и прочие учетные данные нельзя хранить в формате простого текста, 
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будь то в базе данных или в каком-нибудь другом внешнем файле. Чтобы такие 
данные не были раскрыты, их следует зашифровать, обеспечив тем самым до- 
полнительный уровень их защиты. 

В разделе “Тема 19. Контроль версий” главы 3 “Основные инструментальные 
средства” настоятельно рекомендовалось ставить все или почти все, что требу- 
ется для проекта, под систему управления версиями. Из этого правила имеет- 
ся одно важное исключение: не регистрировать секретные данные, ключи АРІ, 
ключи сетевого протокола 58Н, зашифрованные пароли и прочие учетные дан- 
ные вместе с исходным кодом, когда он возвращается после правки в систему 
контроля версий. Управление ключами и секретными сведениями должно осу- 
ществляться отдельно через файлы конфигурации или переменные окружения 
как отдельная стадия процесса сборки и развертывания. 


Организация регулярного обновления системы безопасности 

Обновление вычислительных систем может доставить немало хлопот. Так, 
вставка “заплаты” для обновления системы безопасности может нарушить в ка- 
честве побочного эффекта нормальную работу какой-нибудь части приложения. 
В таком случае можно было бы принять решение отложить обновление до более 
удобного момента. Но такое решение никуда не годится, поскольку приложение 
остается уязвимым к известной эксплуатирующей попытке взлома до тех пор, 
пока не будут обновлены его системы безопасности. 


Устанавливайте обновления системы безопасности 
незамедлительно 


Такой совет касается любого подключенного к сети устройства, включая 
мобильные телефоны, автомобили, бытовую электронику, персональные ком- 
пьютеры, компьютеры для разработки и сборки программ, рабочие серверы и 
“облачные” образы — одним словом, все. И если вы думаете, что это не так уж 
и важно, запомните, что самые крупные взломы данных в истории происходили 
потому, что информационные системы своевременно не обновлялись. Не дово- 
дите того, чтобы нечто подобное случилось и с вами. 


ЗДРАВЫЙ СМЫСЛ И КРИПТОГРАФИЯ 


Очень важно иметь в виду, что здравый смысл может вас подвести, когда 


речь идет о криптографии. Первое и самое главное правило в отношении крип- 


тографии гласит: никогда не реализуйте ее самостоятельно”. 


23 Если, конечно, вы не обладаете ученой степенью в области криптографии. Но даже в 
этом случае вы не должны этого делать без проверок со стороны коллег по работе, об- 
ширных эксплуатационных испытаний с поощрениями за обнаружение уязвимых мест в 
защите проверяемой системы и выделения средств на долгосрочное ее сопровождение. 
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Одно из самых главных затруднений, связанных с обеспечением безопас- 
ности, состоит в том, что качественная защита нередко противоречит здра- 
вому смыслу или обычной практике. У вас может, например, возникнуть 
мысль, что требования к строгости паролей повысят безопасность прило- 
жения или веб-сайта. Но вы окажетесь не правы. 


Правила соблюдения строгости паролей на самом деле снижают уровень 
безопасности. Ниже перечислены вкратце неудачные идеи и некоторые 
рекомендации по обеспечению безопасности от Национального института 
стандартов и технологий США (М№ІЅТ)?*. 


® Не ограничивайте длину паролей меньше чем 64 символами. МТ реко- 
мендует в качестве предельной длины пароля 256 символов. 


® Не обрезайте выбранные пользователями пароли. 


® Не ограничивайте применение специальных символов, таких как [] () ; & 
%5# или /. Если специальные символы в пароле способны скомпромети- 
ровать вашу систему — у вас большие проблемы. М№М$Т требует принимать 
все печатные А$С!-символы, пробел и символы Утсосе. 


ө Не предоставляйте подсказки для паролей неаутентифицированным 
пользователям или приглашения для ввода конкретных типов информа- 
ции (наподобие “Как звали ваше первое домашнее животное?”) 


® Не отменяйте функцию разфе в своем браузере. Нарушение функций 
браузера и диспетчеров паролей не делает вашу систему более безопас- 
ной и фактически побуждает пользователей составлять более простые и 
краткие пароли, которые намного проще разгадать. 


® Не устанавливайте дополнительные правила составления паролей. На- 
пример, не запрещайте использовать в паролях какие-нибудь конкрет- 
ные сочетания прописных и строчных букв, цифр, специальных знаков 
или повторяющихся символов. 


® Не заставляйте волевым порядком пользователей изменять свои пароли 
по истечении некоторого периода времени. Делайте это лишь при веских 
основаниях (например, в случае взлома). 


Поощряйте употребление длинных, произвольных паролей с высокой сте- 
пенью энтропии. Наложение искусственных ограничений сдерживает эн- 
тропию и порождает скверные привычки в отношении паролей, оставляя 
учетные записи пользователей уязвимыми к овладению чужими. 


24 См. специальное издание №М15Т Ѕресіаї РиЫісаіоп 800-63В: Гівіїаї 1аепн!у СиійеЇіпеѕ 
Аиѓіепіісаїоп апа Ілјесусіе МапазететЕ свободно доступное по адресу НЕЕрз:// 
401.ога/10.6028/МТ$ЗТ.5Р.800-63Ъ. 
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Общие нормы практики неверны даже для таких простых вещей, как пароли 
(см. врезку “Антишаблоны для паролей”). Обратившись к криптографии, имейте 
в виду, что даже мельчайшая и едва заметная ошибка способна все нарушить: 
ваш изощренный доморощенный алгоритм шифрования может оказаться разга- 
данным опытным взломщиком в считанные минуты. Поэтому ни в коем случае 
не занимайтесь шифрованием самостоятельно. 

Как упоминалось ранее, полагаться следует лишь на то, что действительно на- 
дежно: хорошо проверенные, тщательно изученные, регулярно сопровождаемые, 
часто обновляемые библиотеки и каркасы — желательно с открытым исходным 
кодом. Если речь не идет о простых задачах шифрования, тщательно проанали- 
зируйте другие связанные с безопасностью функциональные возможности свое- 
го веб-сайта или приложения (например, аутентификацию пользователей). 

Чтобы самостоятельно реализовать функции регистрации с помощью паро- 
ля или биометрической аутентификации, вам придется как следует разобраться 
в принципе действия и назначении хеш-кодов и “соли” для шифрования; по- 
нять, каким образом взломщики пользуются такими средствами, как радужные 
таблицы; выяснить причины, по которым нельзя пользоваться алгоритмами 
шифрования МО5 и ЅНАІ; а также разрешить немало других криптографичес- 
ких вопросов. И даже если вы сделаете все это правильно, то в конечном счете 
именно вам придется отвечать за безопасное хранение данных, учитывая появ- 
ление новых законодательных норм и правовых обязательств. 

С другой стороны, вы можете выбрать прагматичный подход и возложить 
бремя ответственности на кого-нибудь, обратившись, например, к стороннему 
поставщику услуг аутентификации. Это может быть служба, функционирующая 
в вашей организации, или же сторонняя служба, присутствующая в “облаке”. 
Услуги аутентификации нередко предоставляются поставщиками услуг электрон- 
ной почты, телефонной связи или социальных сетей и могут (или не могут) быть 
пригодны для вашего приложения. Но в любом случае поставщики услуг аутен- 
тификации постоянно занимаются подержанием своих систем в безопасном со- 
стоянии и лучше вас разбираются в этих вопросах. Итак, будьте осторожны! 


Другие связанные с данной темой разделы 
® Тема 23. Проектирование по контракту, глава 4 “Прагматичная пара- 
нойя”. 
® Тема 24. Мертвые программы не лгут, глава 4 “Прагматичная паранойя”. 


е Тема 25. Утвердительное программирование, глава 4 “Прагматичная па- 
ранойя”. 


• Тема 38. Программирование по совпадению. 


е Тема 45. Западня требований, глава 8 “До начала проекта”. 


РКА АМИ кое е ТОТУНЫ АУТА ОФ реба ПАТИ лате ГУ Ха РТН ки АМЧ Ф АИ ОЛАМ Р н У нл ати о АЗАРГА ТАР ИА очен ААЛА МУТ ВТСЗЗМАЯ ЖЛЕ Усе ЭМА ВА але деток ча ла АА ладам АЕ ОТ) А Зато не анна 
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ИМЕНОВАНИЕ 


“Называть вещи своими именами — начало мудрости”. 
Конфуций 


Что значит имя? В процессе программирования оно значит “все, что угодно”! 
Разработчики придумывают имена приложениям, подсистемам, модулям, фун- 
кциям, переменным, ведь они постоянно создают что-нибудь новое и каким-то 
образом его называют. Следовательно, имена крайне важны, поскольку они в 
немалой степени выявляют намерения и убеждения разработчиков. 

Мы считаем, что разрабатываемые компоненты должны именоваться в соот- 
ветствии с той ролью, которую они играют в прикладном коде. Это означает, что 
всякий раз, когда вы создаете какой-нибудь компонент, вы должны остановить- 
ся на время и подумать над следующим вопросом: “Для чего я это создаю?” 

И это своевременный и важный вопрос, поскольку он заставляет вас от- 
влечься от решения непосредственной задачи и бросить взгляд на общую кар- 
тину. Рассматривая роль переменной или функции, вы размышляете, для чего 
она предназначена, что она может сделать и как с ней взаимодействовать не- 
посредственно в коде. И зачастую вы осознаете, что предполагаемые вами даль- 
нейшие действия не имеют никакого смысла просто потому, что вам не удалось 
придумать подходящее имя. 

Мысль о том, что имена имеют глубокий смысл, имеет свое научное обосно- 
вание. Оказывается, мозг человека может читать и понимать слова очень быст- 
ро, причем быстрее, чем выполнять многие другие действия. Это означает, что 
слова приобретают определенный приоритет, когда мы пытаемся что-то осмыс- 
лить. И это можно продемонстрировать на примере эффекта Струпа?. 

Взгляните на приведенную ниже панель, где показаны названия цветов и от- 
тенков, выделенных черным или белым цветом либо оттенком серого, хотя на- 
звания и цвета совсем не обязательно совпадают. И вот вам задача: произнести 


вслух название каждого цвета так, как оно написаног. 


25 См. Ѕѓийіеѕ оў Іпіетјетепсе т Зета] Уетђаї Кеасііопзѕ [51:35]. 


26 Имеются два варианта данной панели. В одном из них употребляются разные цве- 
та, а в другом — оттенки серого. Здесь приведен черно-белый вариант данной панели, 
но если вам потребуется цветной ее вариант или же если вы плохо различаете оттенки 
серого, перейдите на веб-страницу, доступную по адресу ВЕЕрз: //ргадргод. сом/ 
{ре-ргадта{1с-ргоадгатмег / ѕзігоор-еЁЁесі. 
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БЕЛЫЙ БЕЛЫЙ СЕРЫЙ 
СЕРЫЙ 


СЕРЫЙ 
ЧЕРНЫЙ БЕЛЫЙ БЕЛЫЙ 
ЧЕРНЫЙ 


Повторите описанные выше действия, но вместо этого произнесите вслух назва- 
ние цвета, которым написано каждое слово. Сделать это труднее, не так ли? Бегло 
прочитать названия цветов проще, чем попытаться распознать сами цвета. Наш 
мозг интерпретирует написанные слова как нечто важное, поэтому нам следует 
сделать так, чтобы употребляемые нами имена отвечали данному наблюдению. 

Рассмотрим ряд примеров. 


® Допустим, на веб-сайте, продающем ювелирные изделия, изготовленные из 


бывших в употреблении графических плат, мы аутентифицируем людей, 
посещающих этот сайт. Это делается следующим образом: 


1еі изег = аціһепіісаіе (сгедепііа1ѕ) 


Переменная иѕег, хранящая результаты аутентификации, называется 
изег, поскольку она всегда обозначает пользователя. Но почему перемен- 
ная называется именно так? Ведь с тем же успехом ее можно было бы на- 
звать соиѕёотег или риуег? Присвоив ей имя пех, мы тем самым пос- 
тоянно напоминаем себе по ходу программирования, что именно данное 
лицо пытается сделать и что это означает для нас самих. 


Допустим, имеется следующий метод экземпляра, в котором рассчитыва- 
ется скидка на заказанные товары: 


рочЬ1іс уоіа аедисеРегсеп® (аоџрІе амойп®) 

РА 

Здесь употребляются два имени. Во-первых, имя метода аӢеацџсіРегсепі 
обозначает, что именно он делает, а не почему он это делает. И во-вторых, 
имя параметра атоипії, по меньшей мере, вводит в заблуждение. Что имен- 
но оно обозначает: абсолютную величину или долю в процентах? 


Возможно, было бы лучше написать следующую строку кода: 


рчр1іс уоіа арр1урізѕсоипі (Регсепіаде ді ѕсоцпі) 

И ааа 

Ведь имя данного метода теперь ясно обозначает его назначение. Кроме 
того, мы изменили тип параметра с аолЬТе на заранее определяемый ссы- 
лочный тип Регсепфаде. Нам ничего неизвестно о намерениях пользова- 
теля данного метода, и поэтому, оперируя долями в процентах, мы можем 
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только гадать, в каких именно пределах будет задано значение параметра 
аіѕсоцпё: от 0 до 100 или же от 0.0 до 1.0. Поэтому указанный тип 
документирует здесь предполагаемое значение параметра данного метода. 


• Допустим, имеется модуль, оперирующий числами Фибоначчи. В одной из 
его функций вычисляется п-е число Фибоначчи. При этом возникает воп- 
рос: как назвать такую функцию? Большинство разработчиков скажут, что 
этой функции следует присвоить имя ір. Такое имя, на первый взгляд, 
вполне обосновано, но не следует забывать, что эта функция будет вызы- 
ваться в контексте данного модуля, например, так: Е1Ю.Е1Ъ (п). А может 
быть, этой функции следует присвоить имя оЕ или пЕВ и вызывать ее так, 
как показано ниже. 


Е1р.о# (0) # => 0 
Р1Ь.пеР (20) # => 4181 


Присваивая имена компонентам, вы постоянно ищете способы прояснить, 
что именно вы имеете в виду, и такое прояснение приведет вас к лучшему по- 
ниманию своего кода по ходу его написания. Тем не менее далеко не все имена 
способны претендовать на соискание литературной премии. 


Исключение, ПОДТВЕРЖДАЮЩЕЕ ПРАВИЛО 


Несмотря на стремление сделать исходный код более ясным, необходимо 
также принимать во внимание и фирменную символику, а это уже совсем 
другой вопрос. 


По установившейся традиции проектам и их командам принято присваивать 
малопонятные, но “умные” названия, например: “Покемон”, “Замечательные 
супергерои”, “Крутые мачо” имена персонажей из серии фильмов “Власте- 
лин колец” в буквальном смысле слова. 


УВАЖЕНИЕ К КУЛЬТУРЕ 


В программировании есть только две трудные вещи: 
инвалидация кеша и именование переменных. 


В большей части литературы по основам программирования читателей пре- 
достерегают никогда не присваивать переменным однобуквенные имена вроде 
і, у или к. Мы считаем, что они не совсем правы. 


27 Знаете ли вы, почему переменная цикла обычно обозначается как і? Дело в том, что 
более 60 лет назад в первоначальной версии языка ЕОКТКАМ (на синтаксис которого ока- 
зала большое влияние алгебра) переменные, имена которых начинались на буквы от І до 
№, были целочисленными. 
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На самом деле это зависит от культуры программирования на конкретном язы- 
ке или его выполняющей среды. Так, в языке С имена і, ј или К традиционно 
употребляются в качестве переменных для увеличения шага цикла, а именем $ 
обозначаются символьные строки и т.д. Если вы программируете именно в такой 
среде, то, именуя элементы кода, следуйте принятым нормам. Иначе вы, по сущест- 
ву, нарушаете эти нормы, а следовательно, поступаете неверно. Уважая сложивши- 
еся традиции, вы вряд ли напишете нечто, подобное приведенному ниже фрагмен- 
ту кода на языке СіІојше, где переменной і присваивается символьная строка. 


(1её [1 "Не11о Иог1а") 
(реп) 


В одних сообществах программистов отдается предпочтение смешанному 
написанию имен вроде саме1Сазе, где употребляются прописные буквы в 
средине имени (так называемый “горбатый регистр”), тогда как в других со- 
обществах — “змеиный регистр” вроде ѕпаке _сазе, где слова, составляющие 
имя, разделяются знаком подчеркивания. В самих языках программирования, 
безусловно, приняты обе разновидности написания имен. Но это не позволяет 
уладить все вопросы, поскольку приходится уважать локальную культуру про- 
граммирования. Так, в некоторых языках в именах компонентов допускается 
использовать символы Юникода. Но, прежде чем употреблять в исходном коде 
такие “заумные” имена, как Јәѕп или =ёрхЕта, необходимо подумать, как это 
будет воспринято в сообществе программистов. 


СОГЛАСОВАННОСТЬ 


Ральф Уолдо Эмерсон однажды написал: “Безрассудная согласованность — 
это пугало для маленьких умов’, но ему не посчастливилось работать в команде 
программистов. В каждом проекте вырабатывается свой словарь терминов — 
жаргонных словечек, имеющих особое значение для членов команды. Так, тер- 
мин отет означает “заказ” для команды, разрабатывающей интернет-магазин, 
тогда как для команды, создающей приложение, графически отображающее про- 
исхождение религиозных групп, — “орден”. В связи с этим очень важно, чтобы 
все члены команды знали эти термины и пользовались ими согласованно. 

С одной стороны, можно поощрять активное общение в команде разработ- 
чиков. Так, если программы пишутся парами, и эти пары часто меняются, то 
терминология усваивается быстро. С другой стороны, можно составить словарь 
проекта, перечислив в нем термины, имеющие особое значение для команды. 
Это неформальный документ, который может поддерживаться в форме вики- 
страниц или карточек для записей, вывешиваемых где-нибудь на стене. 

Со временем терминология проекта станет жить своей жизнью. И как толь- 
ко словарь терминов станет привычным для всех, им можно пользоваться как 
скорописью для точного и краткого обозначения сложных понятий. (На этом, 
собственно, основывается язык шаблонов.) 
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В программировании есть только две трудные вещи: 
инвалидация кеша, именование переменных 
и ошибки выхода за границы массивов 


Сколько ни прилагай усилий, все равно все течет и изменяется. В частнос- 
ти, код реорганизуется, акценты применения смещаются, а смысловое значение 
немного меняется. И если не проявить бдительность в отношении обновления 
имен по ходу программирования, то можно очень быстро дойти до запутанных 
имен, вызывающих еще большие проблемы, чем имена бессмысленные. Прихо- 
дилось ли вам когда-нибудь слышать такое объяснение несогласованностей в 
исходном коде: “Подпрограмма деїраќѓа на самом деле записывает данные в 
архивный файл”? 

Как пояснялось в разделе “Тема 3. Программная энтропия” главы 1 “Фило- 
софия прагматизма’, обнаружив ошибку, ее необходимо безотлагательно устра- 
нить. Так, если вы обнаружите имя, больше не выражающее ваше намерение 
или вводящее в заблуждение, его нужно исправить. Имея в своем распоряжении 
полный набор регрессионных тестов, выявите все экземпляры этого слова, ко- 
торые вы могли пропустить. 


Именуйте правильно; 
а по мере надобности переименовывайте 


Если по какой-то причине вы не можете изменить неверное в настоящий мо- 
мент имя, значит, у вас возникло более серьезное затруднение: нарушен при- 
нцип легкости изменения (см. раздел “Тема 8. Сущность качественного проекти- 
рования” главы 2 “Прагматичный подход”). Сначала разрешите это затруднение, 
а затем измените указавшее на него имя. Упрощайте переименование и делайте 
это почаще. В противном случае вам придется объяснить новым членам своей 
команды, что подпрограмма дче{Ра{а на самом деле записывает данные в файл, 
причем делать это с невозмутимым видом. 


Другие разделы, связанные с данной темой 
® Тема 3. Программная энтропия, глава 1 “Философия прагматизма”. 


® Тема 40. Рефакторинг. 


® Тема 45. Западня требований, глава 8 “До начала проекта”. 
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Задачи 


ә Если вы обнаружите функцию или метод со слишком общим именем, 
попробуйте изменить это имя, чтобы точнее выразить назначение данной 
функции или метода. И тогда вам будет легче реорганизовать свой код. 


® В одном из рассмотренных выше примеров предлагалось употребить более 
конкретные имена вроде риуег или сизсомег вместо более традицион- 
ного и обобщенного имени иѕег. Какими еще именами вы обыкновенно 
пользуетесь как наиболее подходящими в данном случае? 


е Согласуются ли имена в вашей системе с пользовательскими терминами 
из предметной области? Если не согласуются, то почему? Вызвано ли это 
когнитивным диссонансом вроде эффекта Струпа для вашей команды: 


® Трудно ли изменять имена в вашей системе? Что можно сделать, чтобы 
устранить нарушенное в итоге отображение конкретного окна? 


[ЛАВА 8 


В самом начале проекта вам и вашей команде требуется изучить исходные 
требования. Просто приказание, что нужно делать, или выслушать объяснения 
пользователей явно недостаточно, поэтому прочитайте раздел “Западня требо- 
ваний’, чтобы научиться избегать общих ловушек. 

Обыкновенной мудрости и управлению ограничениями посвящен раздел 
“Решение неразрешимым головоломок”. Трудности появятся в любом случае, 
удовлетворяете ли вы требования, выполняете ли анализ, программируете или 
тестируете. Зачастую они бывают еще более серьезными, чем казались вначале. 

Если по ходу проекта перед нами встают неразрешимые трудности, мы лю- 
бим прибегать к своему секретному оружию: работать вместе. Под работой 
вместе мы подразумеваем не коллективный труд над массивным документом 
с требованиями, интенсивный обмен рассылаемыми по электронной почте со- 
общениями или проведение бесконечных совещаний, а совместное разрешение 
затруднений во время программирования. В разделе “Совместная работа” мы 
покажем, как приступить к такой работе, кто и что для этого требуется. 

Несмотря на то что в Манифесте гибкой разработки, в частности, заявле- 
но: “Люди и взаимодействие важнее процессов и инструментов”, буквально все 
“гибкие” проекты начинались с иронического обсуждения процессов и инстру- 
ментальных средств, которые предстоит применять. Но как бы тщательно ни 
был рассмотрен этот вопрос и какие бы нормы передовой практики ни приме- 
нялись, ни одна методика не может заменить способность мыслить. Следова- 
тельно, требуется не конкретный процесс или инструмент, а осмысление самой 
сущности гибкости, как поясняется в соответствующем разделе. 

Разобрав все самые важные вопросы до начала проекта, можно лучше под- 
готовиться к работе над ним, чтобы избежать “аналитического паралича’, когда 
много мыслей, да мало толку, и фактически начать, а затем успешно завершить 
проект. 
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ЗАПАДНЯ ТРЕБОВАНИЙ 


“Совершенство достигается не тогда, когда нечего 
добавить, а когда нечего отнять...” 


Антуан де Сент-Экзюпери, Планета людей, 1939 г. 


Во многих книгах и учебных пособиях сбор требований объясняется как ран- 
няя стадия проекта. Слово “сбор” здесь, по-видимому, означает племя счаст- 
ливых аналитиков, собирающих повсюду крупицы мудрости под звуки “Пасто- 
ральной симфонии” Людвига ван Бетховена, исполняемой на заднем плане. Кро- 
ме того, слово “сбор” подразумевает, что требования уже существуют, остается 
лишь найти и разместить их в своей корзине и беззаботно идти своим путем. 

В действительности все обстоит совсем иначе. Ведь требования редко лежат на 
поверхности. Как правило, они зарыты глубоко под слоями допущений, недоразу- 
мений и убеждений. Хуже того, требования зачастую вообще не существуют. 


Никто точно не знает, чего он хочет 


Мид о ТРЕБОВАНИЯХ 


На заре истории разработки программного обеспечения ЭВМ были более цен- 
ными (с точки зрения амортизированной стоимости часа работы), чем люди, кото- 
рые на них работали. Поэтому программисты экономили средства, пытаясь сделать 
свои программы работоспособными сразу. В ходе этого процесса они старались 
точно указать, что должна делать ЭВМ. И с этой целью составлялась специфика- 
ция требований, которая превращалась сначала в проектную документацию, а за- 
тем в блок-схемы и псевдокод и, наконец, в исходный код. Но, прежде чем ввести 
исходный код в ЭВМ, программисты тщательно проверяли его за столом. 

Такой подход к разработке программного обеспечения обходится очень доро- 
го. И столь большие затраты послужили причиной того, что программисты стара- 
лись автоматизировать что-нибудь лишь тогда, когда они точно знали, чего хотят 
добиться. А поскольку вычислительные возможности первых ЭВМ были очень 
скромными, круг решаемых задач был весьма ограниченным. В частности, можно 
было полностью понять задачу еще до того, как приступить к ее решению. 

Но в реальном мире все обстоит совсем иначе. В нем царит беспорядок, кон- 
фликты и много неизвестного. В таком мире точные спецификации чего-нибудь 
редки, если они вообще возможны. 

И здесь вступают в действие программисты. Их задача — помочь людям по- 
нять, чего они хотят на самом деле. И это, вероятно, самое ценное преимущест- 
во программистов, так что повторим еще раз: 
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Программисты помогают людям понять, 
чего они не хотят на самом деле 


ПРОГРАММИРОВАНИЕ КАК ТЕРАПИЯ 


Назовем клиентами тех людей, которые просят нас написать программу. 

Типичный клиент приходит к нам со своей нуждой, которая может быть как 
стратегической, так и тактической потребностью отреагировать на возникшее 
затруднение. Это может быть потребность изменить существующую систему 
или создать новую. Иногда она выражается в деловых терминах, а порой — в 
технических. 

Ошибка, которую часто совершают разработчики, состоит в том, что они 
воспринимают сформулированную их клиентами потребность как задачу и ре- 
ализуют ее решение. На самом деле это лишь приглашение к исследованию, хотя 
клиент может этого и не осознавать. 

Рассмотрим простой пример. Допустим, что вы работаете в издательстве, 
выпускающем книги как в печатном, так и в электронном виде. Вам поставили 
новое требование, сформулированное следующим образом: 


Доставка должна быть бесплатной по всем заказам стоимостью свы- 
ше 50 долларов. 


Призадумайтесь на секунду и поставьте себя на место заказчика. Какие мыс- 
ли придут вам сразу на ум? Скорее всего, у вас возникнут следующие вопросы: 


ө Включает ли сумма заказа 50 долларов налог? 
е Включает ли сумма заказа 50 долларов текущие транспортные расходы: 


® Распространяется ли сумма заказа 50 долларов только на печатные изда- 
ния или же может охватывать и электронные книги: 


е Какой вид доставки имеется в виду? Срочная? Наземным транспортом? 
® А как насчет международных заказов? 


® И как часто предельная сумма заказа 50 долларов будет изменяться в даль- 
нейшем? 


Когда вам дают простое задание, рассматривайте крайние случаи, докучая 
тем, кто вам его дал, подробными вопросами, чтобы прояснить дело. Скорее 
всего, клиент уже думал о некоторых из этих крайних случаев и лишь подразу- 
мевал, что они будут учтены в реализации. Задавая наводящие вопросы, можно 
выведать все эти сведения. 

Но другие вопросы могут, вероятнее всего, касаться того, о чем клиент рань- 
ше даже не задумывался. Именно здесь и начинается самое интересное, а гра- 
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мотный разработчик учится быть дипломатом, как демонстрируется в приве- 
денном ниже диалоге с клиентом. 


Вы: У нас возникли вопросы по поводу итоговой суммы заказа 50 долла- 
ров. Входят ли в эту сумму обычно взимаемые транспортные расходы? 


Клиент: Конечно. Это все, что заказчики должны заплатить. 


Вы: Заказчики должны ясно и просто усмотреть в этом привлекатель- 
ность такого предложения. Но мне представляется, что некоторые 
менее добросовестные заказчики попытаются обойти эти правила на- 
шей системы заказов. 


Клиент: Каким образом? 


Вы: Допустим, они покупают сначала книгу за 25 долларов, а затем 
выбирают ночную доставку как самый дорогой вариант. В таком слу- 
чае доставка книги будет, вероятнее всего, стоить около 30 долларов, 
а общая сумма заказа составит 55 долларов. Если мы делаем доставку 
бесплатной, то за ночную доставку книги стоимостью 25 долларов они 
заплатили бы всего 25 долларов. 


(В этот момент опытный разработчик делает многозначительную 
паузу. Он изложил факты, а решение принимать клиенту.) 


Клиент: Ой, да это совсем не то, что я предполагал! Ведь мы понесем 
убытки на таких заказах. Есть ли какие-то пути выхода из этого по- 
ложения? 


Именно здесь и начинается исследование исходных требований. Ваша роль — 
интерпретировать то, что говорит клиент, и в ответ пояснить ему возможные 
последствия. Это одновременно интеллектуальный и творческий процесс, пос- 
кольку вы обдумываете требования и в то же время способствуете принятию 
такого решения, которое, скорее всего, окажется лучше, чем то, что могло бы 
быть принято вами или клиентом по отдельности. 


ТРЕБОВАНИЯ — ЭТО ПРОЦЕСС 


В приведенном выше примере разработчик принял требования и в ответ 
объяснил их последствия клиенту, что и послужило началом для их исследова- 
ния. В ходе этого исследования вы, вероятно, придумаете еще множество воп- 
росов, реагируя на предлагаемые клиентом варианты решений. Это реальность 
любого сбора требований. 


Требования изучаются с помощью обратной связи 
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Ваша задача — помочь клиенту лучше понять последствия сформулирован- 
ных им требований. Для этого вы образуете цепь обратной связи, пользуясь 
которой клиент может обдумывать и уточнять свои требования. 

В приведенном выше примере выразить обратную связь словами было не- 
трудно, но так бывает далеко не всегда. Иногда вы просто недостаточно знаете 
особенности предметной области для этого. 

В подобных случаях программисты-прагматики полагаются на методику от- 
ветной реакции вроде наводящего вопроса: “Вы имели в виду именно это?” Они 
создают макеты и прототипы и дают клиентам возможность поэкспериментиро- 
вать с ними. В идеальном случае макеты и прототипы получаются достаточно 
гибкими, чтобы их можно было изменять прямо во время бесед с клиентами и 
реагировать на их замечания вроде “это не то, что я имел в виду’ репликами 
типа “а вот так больше похоже на то, что вы хотели?”. 

Иногда такие макеты и прототипы могут быть отвергнуты в течение часа или 
около того. Очевидно, что они являются лишь поделками, подсказывающими 
общий замысел. 

Но на практике вся работа, которую разработчикам приходится выполнять, 
на самом деле является некоторой формой макетирования. И даже в конце про- 
екта мы все еще интерпретируем таким образом пожелания своих клиентов. 
Фактически к этому времени количество клиентов только возрастает, включая 
сотрудников отделов контроля качества, эксплуатации, сбыта, а возможно, и 
тестовых групп потенциальных пользователей. 

Таким образом, программист-прагматик рассматривает весь проект как 
большое упражнение в сборе требований. Именно поэтому мы предпочитаем 
краткие, но частые беседы с клиентами, чтобы получать их непосредственную 
реакцию. Это дает нам возможность быть в курсе дела и быть уверенными, что 
в том случае, если мы пойдем по неверному пути, потраченное на него время 
сведется к минимуму. 


ПостАВЬТЕ СЕБЯ НА МЕСТО КЛИЕНТА 


Чтобы лучше понять ход мыслей клиента, достаточно воспользоваться прос- 
тым, но нечасто применяемым методом: поставить себя на место клиента. Так, 
если вы разрабатываете систему для службы технической поддержки, проведите 
пару дней рядом с опытным сотрудником этой службы, следя за тем, как он от- 
вечает на звонки. А если вы автоматизируете систему ручного контроля запасов, 
поработайте с неделю на складе". 


1! Целая неделя — не слишком ли это долго? Нет, не слишком, особенно в том случае, если 
требуется проанализировать производственные процессы, где руководители и исполнители 
работают в разных условиях. Руководители поделятся с вами одним (зачастую самым общим) 
представлением о производственных процессах, а когда вы опуститесь на землю, то столк- 
нетесь с совершенно иной реальностью, на усвоение которой также потребуется время. 
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Помимо ясного понимания, каким образом проектируемая система будет 
применяться на практике, вы будете приятно удивлены тем, как ваша просьба 
понаблюдать за производственными процессами непосредственно на рабочих 
местах поможет установить доверие и создать прочный фундамент для общения 
с вашими клиентами. Только не мешайте людям работать! 


Работайте с пользователем, чтобы мыслить как пользователь 


Во время сбора ответной реакции стоит начать выстраивать тесные отноше- 
ния со своей клиентурой, изучая ожидания и надежды клиентов в отношении 
проектируемой вами системы. Подробнее об этом см. в разделе “Тема 52. Достав- 
ляйте своим пользователям удовольствие” главы 9 “Прагматичные проекты”. 


ТРЕБОВАНИЯ И ПРАВИЛА 


Представьте, что в беседе с сотрудниками отдела кадров клиент заявит: “За- 
писи о работниках могут просматривать только их непосредственные начальни- 
ки и сотрудники отдела кадров”. Следует ли считать такое заявление истинным 
требованием? Возможно, в настоящий момент так и стоит поступать, но оно 
включает в себя определенный набор бизнес-правил. 

Отличия бизнес-правил от требований едва заметны, но тем не менее они 
могут иметь глубокие последствия для разработчиков. Так, если требование 
сформулировано следующим образом: “Только непосредственные начальники и 
сотрудники отдела кадров могут просматривать записи о работниках’, то разра- 
ботчик может в конечном счете запрограммировать и проверять это требование 
явным образом всякий раз, когда приложение получает доступ к данным. Но 
если требование сформулировано таким образом: “Записи о работниках могут 
быть доступны только уполномоченным пользователям”, то разработчик, ве- 
роятнее всего, спроектирует и реализует некоторого рода систему управления 
доступом. И если бизнес-правила изменятся (а это неизбежно), то обновить 
придется только метаданные такой системы. Фактически сбор требований ес- 
тественным образом приводит к системе, хорошо приспособленной к поддержке 
метаданных. 

В действительности общее правило таково: 


Бизнес-правила — это метаданные 


Реализуйте общий случай, приняв во внимание сведения о бизнес-правилах 
в качестве примера того, что должно поддерживаться в системе. 
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ТРЕБОВАНИЯ И РЕАЛЬНОСТЬ 


В статье из журнала іЯ, вышедшей в январе 1999 года?, продюсер и музыкант 
Брайан Эно описал невероятную на то время технологию окончательного микши- 
рования звука на одном пульте. Однако эта технология только мешала творческо- 
му процессу вместо того, чтобы дать музыкантам возможность создавать более 
качественную музыку, а звукорежиссерам — записывать ее быстрее и дешевле. 

Чтобы стали понятнее причины, выясним, каким образом работают звуко- 
режиссеры. Они выполняют сведение звука, руководствуясь своей интуицией. 
С годами у них вырабатывается внутренняя цепь обратной связи между их уша- 
ми и пальцами, перемещающими ползунки регуляторов громкости, вращающи- 
ми рукоятки балансировки звуковых каналов и т.д. Тем не менее все эти про- 
фессиональные способности звукорежиссеров в упомянутом выше микшерском 
пульте учтены не были. Вместо этого его пользователи вынуждены были вводить 
данные с клавиатуры или щелкать кнопками мыши. Пульт обеспечивал все не- 
обходимые для звукозаписи функции, но они были реализованы незнакомым и 
чуждым звукорежиссерам образом. Зачастую очень нужные звукорежиссерам 
функции этого микшерского пульта были скрыты за непонятными названиями 
или же становились доступными через неинтуитивные комбинации основных 
функциональных средств. 

Данный пример наглядно иллюстрирует наше убеждение, что удобные инс- 
трументы должны быть приспособлены к рукам мастера, который ими пользует- 
ся. Обычно это положение учитывается при удачном сборе требований. И поэ- 
тому ранняя ответная реакция, достигаемая с помощью прототипов или методом 
трассирующих пуль, приводит к реакции клиентов “Да, система делает то, что 
мне требуется, но не так, как я хочу”. 


ДокумеНТИРОВАНИЕ ТРЕБОВАНИЙ 


Мы считаем самой лучшей и, возможно, единственной документацией тре- 
бований рабочий код. Но это совсем не означает, что можно обойтись без доку- 
ментирования своего понимания того, что требуется клиенту. Это просто озна- 
чает, что такие документы не выпускаются, т.е. не даются клиентам на подпись. 
Вместо этого они просто служат вехами, помогающими направить процесс реа- 
лизации требований в нужное русло. 


Требования документируются не для клиентов 

В прошлом мы оба работали над проектами, в ходе которых составлялись 
невероятно подробные требования. Такие основательные документы существен- 
но расширяли исходное двухминутное пояснение клиентом его требований к 
проекту до образцового произведения толщиной с целый дюйм, испещренного 


2 См. по адресу ПЕЕрз: //мим.м1геа. сот/1999/01/епо/. 
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диаграммами и таблицами. В подобных документах требования уточнялись на- 
столько, что их реализация почти не допускала никакой неоднозначности. Если 
бы можно было применить к такому документу современные довольно эффек- 
тивные инструментальные средства, его можно было бы сразу превратить в го- 
товую программу. 

Составление таких документов было ошибкой по двум причинам. Во-первых, 
как обсуждалось ранее, клиенту на самом деле неизвестно, что ему, собственно, 
требуется. Следовательно, превращая то, что заявлено клиентом, в едва ли не 
нормативно-правовой документ, разработчики пытаются построить невероятно 
сложный замок на зыбучих песках. 

На это вы могли бы возразить: “Но ведь когда мы приносим документ кли- 
енту на подпись, то получаем его ответную реакцию”. И это приводит нас ко 
второй причине, по которой такое документирование требований ошибочно: 
клиент вообще не читает спецификации требований к программному обеспе- 
чению. 

Клиенты прибегают к услугам программистов потому, что программисты 
вникают в мельчайшие подробности, тогда как клиента интересует лишь общее 
решение не совсем ясно поставленной им задачи. Документация на требования 
составляется для разработчиков и содержит подробные сведения, которые иног- 
да непонятны, а зачастую неинтересны самому клиенту. 

Выпустите документацию требований объемом 200 страниц, и клиент, веро- 
ятнее всего, решит: если она столь объемистая, значит, достаточно важная. Он 
может позволить себе прочитать два первых ее абзаца (именно поэтому они и 
называются резюме для руководства) и бегло просмотреть все остальное, изред- 
ка останавливаясь на аккуратно построенной диаграмме. 

Документация не подавляет клиента. Но предоставить ему крупную техни- 
ческую документацию — это все равно, что дать разработчику средней квали- 
фикации экземпляр “Илиады” Гомера и попросить его написать на ее основе 
видеоигру. 


Требования документируются для планирования 

Итак, мы не верим в монолитную и настолько тяжелую, что ею можно оглу- 
шить и быка, документацию требований к проекту. Но мы знаем, что требова- 
ния должны быть написаны просто потому, что разработчикам нужно знать, 
что им делать в команде. 

Какую же форму должна принимать такая документация? Мы предпочитаем 
нечто, способное уместиться на реальной (или виртуальной) карточке для запи- 
сей. Столь краткие записи обычно называются пользовательскими историями, 
описывающими, что именно должна делать небольшая часть приложения с точ- 
ки зрения его пользователя. Если требования написаны именно таким образом, 
их можно разместить на доске и переставлять их, чтобы показать состояние и 
приоритетность их выполнения. 
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Вы можете, конечно, возразить, что на одной карточке для записей нельзя 
уместить все сведения, необходимые для реализации компонента приложения, и 
будете совершенно правы. Но это лишь частичный довод. Стремясь к краткости 
формулировки требований, вы побуждаете разработчиков задавать уточняю- 
щие вопросы. И в то же время усиливаете процесс ответной реакции клиентов и 
программистов на взаимные действия до и во время создания фрагмента кода. 


ИзлишНЕ ПОДРОБНАЯ СПЕЦИФИКАЦИЯ 


Еще одна немалая опасность документирования требований состоит в том, 
что они могут оказаться слишком подробными. Грамотно составленные требо- 
вания абстрактны. Простейшая формулировка, точно отражающая потребности 
в конкретной предметной области, подходит в качестве требования лучше все- 
го. Это совсем не означает, что требования могут быть неопределенными. В их 
формулировке необходимо зафиксировать исходные семантические инварианты 
и задокументировать конкретные или текущие нормы практики выполнения ра- 
бот в виде набора правил. Требования не имеют никакого отношения к архитек- 
туре, конструкции или пользовательскому интерфейсу. Требования отражают 
потребность. 


“ЕщЕ ОДНУ МЯТНУЮ ВАФЕЛЬНУЮ ПЛАСТИНКУ...” 


Многие неудачи в проектах объясняются расширением их границ, иначе име- 
нуемым раздуванием либо расползанием функциональных возможностей или 
требований. Это похоже на синдром сваренной лягушки (см. раздел “Тема 4. 
Суп из камней и вареные лягушки” главы 1 “Философия прагматизма”). Что же 
можно сделать, чтобы избежать расползания требований? . 

Ответ снова кроется в обратной связи. Так, если вы работаете с клиентом 
в режиме последовательных итераций с обратной связью, то клиент будет на 
собственном опыте испытывать воздействие “еще одного функционального 
средства”. Увидев, как очередная карточка с пользовательской историей пере- 
местилась вверх по доске, он поможет выбрать следующую карточку, чтобы пе- 
рейти к следующей итерации и освободить место на доске. И в обоих случаях 
срабатывает обратная связь. 


ВЕДЕНИЕ СЛОВАРЯ ТЕРМИНОВ ПРОЕКТА 


Как только вы начнете обсуждать требования, пользователи и знатоки пред- 
метной области тотчас воспользуются определенными терминами, имеющими 
для них конкретный смысл. Они, например, могут проводить различие между 


? Кульминационный момент интермедии Мистер Креозот в исполнении англий- 
ской группы комиков “Монти Пайтон”; см. по адресу ВЕЕрз: / /мии . уоџіире.сот/ 
маёсћ?у=бхКпепоҮС7І. 
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понятиями “клиент” и “заказчик”, поэтому в системе нецелесообразно пользо- 
ваться тем или иным из этих понятий случайно. 

Во избежание подобных недоразумений рекомендуется создать и вести сло- 
варь терминов проекта как единое место, где определяются все конкретные 
термины, употребляемые в проекте. Все участники проекта, от конечных поль- 
зователей до персонала технической поддержки, должны пользоваться этим 
словарем ради согласованности своих действий. При этом подразумевается, что 
словарь терминов должен быть широко доступным, что служит веским доводом 
в пользу онлайн-документации. 


Пользуйтесь словарем терминов проекта 


В проекте нельзя достичь успеха, если пользователи и разработчики назы- 
вают один и тот же предмет по-разному (или, что еще хуже, называют разные 
предметы одинаково). 


Другие разделы, связанные с данной темой 


® Тема 5. Подходящее программное обеспечение, глава 1 “Философия праг- 
матизма”. 


® Тема 7. Общайтесь!, глава 1 “Философия прагматизма". 
• Тема 11. Обратимость, глава 2 “Прагматичный подход”. 
® Тема 13. Прототипы и памятные записки, глава 2 “Прагматичный подход”. 
ѕ Тема 23. Проектирование по контракту, глава 4 “Прагматичная паранойя". 
е Тема 43. Будьте осторожны, глава 7 “По ходу кодирования”. 
о Тема 44. Именование, глава 7 “По ходу кодирования”. 
$ Тема 46. Решение неразрешимых головоломок, глава 8 “До начала проекта’. 
» Тема 52. Доставляйте своим пользователям удовольствие, глава 9 “Праг- 
матичные проекты". 
Упражнения 


33. Какие из перечисленных ниже требований, вероятнее всего, окажутся ис- 
тинными? Переформулируйте, если это возможно, не истинные требования, 
чтобы они стали более полезными. 


1) Время реакции должно быть меньше -500 мс. 
2) У модальных окон должен быть серый фон. 


3) Приложение должно быть организовано в виде целого ряда внешних про- 
цессов и внутреннего сервера. 
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4) Если пользователь введет нечисловые символы в числовое поле, начнется 
мигание фона этого поля, а введенные данные будут отвергнуты. 


5) Код и данные для данного встроенного приложения должны вписываться 
в пределы 32 Мбайт. 


Задачи 


• Можете ли вы сами воспользоваться программой, которую пишете? Мож- 
но ли иметь ясное представление о требованиях без возможности самому 
пользоваться написанной программой? 


• Выберите задачу, не связанную с вычислительной техникой и требующую 
безотлагательного решения в настоящий момент. Составьте требования 
для решения этой задачи. 


Е И ПН ОО О О 1 О Я О В ОВ О гда ЗИ РУ ана 


| РЕШЕНИЕ НЕРАЗРЕШИМЫХ ГОЛОВОЛОМОК 


Гордий, иарь Фригии, однажды завязал такой узел, 
который никому не удавалось развязать. Считалось, 
что тот, кто разгадает тайну гордиева узла, будет 

править Азией. И вот явился Александр Македонский 
и разрубил гордиев узел мечом на куски. Это была всего 
лишь иная интерпретация требований. И в конечном 
счете он действительно правил большей частью Азии. 


Время от времени вы обнаруживаете, что оказались посредине проекта, и 
вам приходится решать по-настоящему трудную головоломку — техническую 
задачу, с которой вы не можете справиться, или фрагмент кода, написать кото- 
рый оказалось труднее, чем вы думали. Разрешить возникшее затруднение вроде 
бы невозможно, но так ли это трудно сделать, как кажется на первый взгляд? 

Рассмотрим настоящие головоломки, состоящие из фигурных кусочков де- 
рева, ковкого металла или пластмассы, которые обычно дарят детям на Рождес- 
тво или которые можно найти среди распродаваемых домашних вещей. Чтобы 
решить такую головоломку, достаточно снять кольцо, разместить Т-образные 
кусочки в коробке или сделать что-нибудь другое. 

Итак, вы тянете за кольцо или пытаетесь разместить Т-образные кусочки в 
коробке и тотчас убеждаетесь, что очевидные решения здесь не годятся. Решить 
головоломку таким способом нельзя. Но очевидность этого вывода не останав- 
ливает людей в их попытках делать то же самое снова и снова, надеясь, что та- 
ким способом удастся разгадать головоломку. 
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Решение, конечно, лежит где-то в другом месте. Секрет решения любой голо- 
воломки состоит в том, чтобы выявить настоящие (а не мнимые) ограничения и 
найти решение с их учетом. При этом одни ограничения абсолютны, а другие — 
лишь предубеждения. Абсолютные ограничения должны непременно учитывать- 
ся, какими бы неугодными или нелепыми они ни были. Но, с другой стороны, 
некоторые очевидные ограничения могут вообще оказаться не настоящими (что 
и доказал на деле Александр Македонский). Такими же коварными могут ока- 
заться и многие задачи в разработке программного обеспечения. 


СТЕПЕНИ СВОБОДЫ 


Модное выражение “творческое, нешаблонное мышление” побуждает нас 
распознавать ограничения, которые могут оказаться не таковыми, и пренебречь 
ими. Но эта фраза не совсем точна. Так, если шаблон — это граница ограниче- 
ний и условий, то нужно найти такой шаблон, который может оказаться значи- 
тельно большим, чем кажется на первый взгляд. 

Самое главное в разгадывании головоломок — уметь распознавать наклады- 
ваемые ограничения и имеющиеся степени свободы, поскольку именно в них 
находится решение. Некоторые головоломки столь эффективны именно потому, 
что, разгадывая их, можно слишком легко отклонить потенциальные решения. 

Например, сможете ли вы соединить все точки на приведенном ниже рисун- 
ке таким образом, чтобы вернуться в исходную точку, проведя всего лишь три 
прямые линии, не поднимая ручку от бумаги и не возвращаясь по своим следам 
назад (см. Май Ри221е5 & Сатеѕ [Но]92]): 


Необходимо преодолеть любые предубеждения и проверить, являются ли 
они настоящими, незыблемыми ограничениями. И дело не в том, мыслите ли 
вы шаблонно или нешаблонно, а в том, как найти шаблон, выявив тем самым 
настоящие ограничения. 


Вместо того чтобы мыслить нешаблонно, находите шаблон 


Столкнувшись с трудноразрешимой задачей, перечислите все возможные 
пути, которые опробовали прежде. Не отвергайте ни одного из этих путей, ка- 
ким бы бесполезным или нелепым он ни казался. Затем пройдитесь по списку 
всех путей и поясните, почему нельзя выбрать тот или иной путь. Насколько вы 
в этом уверены и сможете ли вы это доказать? 
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Обратимся к троянскому коню — эпическому примеру решения труднораз- 
решимой задачи. Как войску проникнуть незаметно в укрепленный стенами 
город? Можно побиться об заклад, что решение пробиться через ворота было 
сразу отвергнуто как самоубийственное. 

Разделите свои ограничения по категориям и приоритетам. Когда столяры 
приступают к работе, они отрезают сначала самый длинный кусок, затем из ос- 
тавшегося дерева — куски покороче. Аналогично требуется выявить сначала са- 
мые жесткие ограничения и подогнать под них все остальные. Между прочим, 
решение упомянутой выше головоломки с четырьмя точками, соединяемыми 
тремя прямыми линиями, приведено в конце приложения с решениями неко- 
торых задач. 


Идите СВОИМ ПУТЕМ! 


Иногда приходится работать над задачей, которая кажется намного труднее, 
чем думалось изначально. Возможно, при этом возникает ощущение, что был 
выбран неверный путь и должно быть какое-то более простое решение! А мо- 
жет быть, трудноразрешимая задача возникла на завершающей стадии работы 
над проектом, и вы уже отчаялись довести свою систему до работоспособного 
состояния. 

Это идеальный момент отвлечься немного на что-нибудь другое, например, 
пойти на прогулку с собачкой или просто поспать. 

Ваш мозг осознает стоящую перед вами задачу, но на самом деле он немного 
глуповат (только без обид). Поэтому самое время задействовать ваш настоящий 
ум — эту поразительную ассоциативную нейронную сеть, скрывающуюся в под- 
сознании. И вы будете удивлены, как часто в вашем уме возникает ответ, когда 
вы намеренно отвлекаетесь от мучающей вас задачи. 

На первый взгляд, все это кажется слишком таинственным, но на самом деле 
это совсем не так. В журнале Р5усноюову Тодау“ по этому поводу сообщается сле- 


дующее: 


Откровенно говоря, люди, отвлекавшиеся от решения сложной задачи, 
добивались больших успехов, чем люди, которые прилагали для этого 
сознательные усилия. 


Если вы по-прежнему стремитесь отложить на время решение задачи, то сле- 
дующий наилучший шаг, вероятно, состоит в том, чтобы найти кого-нибудь и 
пояснить ему свои трудности. И зачастую отвлечение просто на беседу с кем- 
нибудь приводит к прозрению. 


4 См. по адресу ВЕфрз: / /иму . рѕзусһо1одуіодау. сот/цѕ/р1од/уоцог-ргаіп-могк/ 
201209/5ёор-ігуіпа-ѕо1уе-ргор1етѕ. 


310 Глава 8 = До начала проекта 


Беседуя с кем-нибудь, дайте ему возможность задать вопросы, аналогичные 
перечисленным ниже. 


= Почему вы решаете эту задачу: 
е Какие преимущества дает ее решение? 


® Связаны ли возникшие у вас трудности с крайними случаями? Можно ли 
их исключить? 


® Есть ли более простая родственная задача, которую вы могли бы решить? 


Это еще один характерный пример употребления на практике метода рези- 
нового утенка. 


СУДЬБА БЛАГОВОЛИТ ПОДГОТОВЛЕННОМУ УМУ 


Известный французский ученый-микробиолог Луи Пастер как-то сказал: 


“Что касается наблюдения, 
то судьба благоволит подготовленному уму”. 


Это высказывание справедливо и для решения задач. Чтобы дойти до момен- 
тов прозрения, необходимо бессознательно накопить немало сырого материала; 
предыдущий опыт может способствовать выработке правильного решения. 

Чтобы дать своему уму необходимую пищу для размышлений, лучше всего, 
когда вы выполняете свою повседневную работу, проанализировать отзывы о 
том, что работает и что не работает. Для этого удобно вести технический днев- 
ник, как пояснялось в разделе “Тема 22. Технические дневники” главы 3 “Основ- 
ные инструментальные средства”. И никогда не забывайте совет, начертанный 
на обложке книги Тйе НисйКег$ Сие іо һе Сааху’: НЕ ПАНИКУЙ! 


Другие разделы, связанные с данной темой 


е Тема 5. Подходящее программное обеспечение, глава 1 “Философия праг- 
матизма”. 


ә Тема 37. Прислушивайтесь к своим инстинктам, глава 7 “По ходу кодиро- 
» 
вания. 


® Тема 45. Западня требований. 


е На эту тему Энди написал целую книгу под названием Ргавтайс ТииЕтя 
апа І еатпіпу: Кејасіот Уоит УеНтате [Нип08]. 


Е Научно-фантастический роман английского писателя Дугласа Адамса (Юоцеаѕ АЧапаз; 
в русском переводе — Автостопом по галактике), по мотивам которого была создана 
одноименная компьютерная игра и целый телесериал. — Примеч. пер. 
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Задачи 


® Тщательно проанализируйте любую трудную задачу, которую вам прихо- 
дится решать в настоящее время. Удастся ли вас разрубить этот гордиев 
узел? Вынуждены ли вы поступать именно таким образом и следует ли это 
вообще делать? 


® Представляли ли вы себе все множество ограничений, когда отдавали на 
подпись свой текущий проект? Применимы ли они до сих пор и верна ли 
по-прежнему их интерпретация: 


В ОС О С о О Я Е А О и АТТАМА о О оО ЧАР оа Е оО У тС чм 


' СОВМЕСТНАЯ РАБОТА 


“Мне никогда не встречался человек, желающий 
прочитать 17 тысяч странии документации, 
и если бы такой человек нашелся, я бы его убил, 
чтобы удалить его из генофонда”. 


Джозеф Костелло, президент компании Сайепсе Оеяюп $уѕіетѕ 


Это был один из тех “невозможных” проектов, о которых вам, вероятно, при- 
ходилось слышать как о воодушевляющих и одновременно ужасающих. Сущест- 
вование морально устаревшей системы приходило к концу, а оборудование было 
физически изношено, и поэтому совершенно новая система была призвана заме- 
нить старую в точном соответствии с (зачастую недокументированным) режи- 
мом ее работы. Через эту систему проходили многие сотни миллионов долларов 
чужих людей, а ее новая версия должна была быть создана от начальной стадии 
проектирования и до конечной стадии развертывания в считанные месяцы. 

Именно тогда и познакомились Энди и Дэйв — авторы этой книги как участ- 
ники столь невозможного проекта с нелепыми предельными сроками выполне- 
ния. Шумному успеху этого проекта способствовало лишь одно обстоятельство: 
специалист, который должен был управлять данной системой годами, сидел в 
своем кабинете прямо напротив нашего похожего на чулан для метел помеще- 
ния, где мы занимались разработкой. Так что он был постоянно доступен для 
вопросов, уточнений, решений и демонстраций промежуточных результатов 
нашей работы. 

На страницах данной книги мы уже не раз рекомендовали работать в тесном 
контакте с пользователями, считая их частью команды разработчиков. В своем 
первом совместном проекте мы практиковали то, что теперь можно было бы 
назвать парным или групповым программированием, когда один программист 
набирает исходный код, тогда как другой программист или несколько членов 
команды комментируют, анализируют и решают задачи вместе с ним. Это весь- 
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ма эффективный способ совместной работы, заменяющий бесконечные сове- 
щания, памятные записки и раздутую до бюрократических размеров докумен- 
тацию, которая может похвалиться лишь своим весом, а не полезностью. Под 
совместной работой мы подразумеваем следующее: не просто задавать вопросы, 
вести дискуссии и делать замечания, но делать все это непосредственно по ходу 
программирования. 


_ Закон Конвея 


В 1967 году Мелвин Конвей выдвинул в своей статьей Нои до Соттее$ 
Іпуепі? [Сопб8] следующую идею, которая затем стала называться законом 
Конвея: 


“Организации, проектирующие системы, ограничиваются проектны- 
ми решениями, копирующими структуру связей в этих организациях" 


Таким образом, социальные структуры и каналы связи команды разработчи- 
ков с их организацией отражаются в проектируемом приложении, веб-сай- 
те или ином программном продукте. Различные исследования эмпирически 
подтвердили эту идею. И мы можем засвидетельствовать, что неоднократно 
наблюдали действие закона Конвея на практике. Например, в одних коман- 
дах, члены которых вообще не общаются друг с другом, проектируются ра- 
зобщенные системы, а командах, разделенных надвое, получаются проекты 
типа “клиент-сервер”. 


Исследования эмпирически подтвердили и обратный принцип: структуру 
своей команды можно сознательно организовать по аналогии с требующей- 
ся структурой исходного кода. Например, в географически распределенных 
командах проявляется тенденция к разработке программного обеспечения, 
носящего более модульный и распределенный характер. 


Но самое главное — команды разработчиков, включающие в себя пользо- 
вателей, будут производить программное обеспечение, ясно отражающее 
их непосредственное участие в разработке. И это будет отражаться даже на 
тех командах, которые не особенно заботятся о привлечении пользовате- 
лей к разработке программного обеспечения. 


ПАРНОЕ ПРОГРАММИРОВАНИЕ 


Парное программирование является одной из тех норм практики экстремаль- 
ного программирования, которые нашли широкое распространение за его пре- 
делами. При парном программировании один разработчик вводит исходный код 
на клавиатуре, а другой анализирует введенный код. Они совместно работают 
над решением одной задачи и могут по мере надобности периодически меняться 
своими обязанностями. 


Тема 47 • Совместная работа 313 


Парное программирование дает немало преимуществ. Разные люди привно- 
сят в него разную подготовку и опыт, различные методы и подходы к решению 
задач с разной степенью сосредоточенности внимания на любой конкретной за- 
даче. В частности, разработчик, вводящий исходный код с клавиатуры, должен 
быть сосредоточен на рядовых подробностях синтаксиса и стиля программи- 
рования, тогда как другой разработчик волен рассматривать общие вопросы в 
пределах решаемой задачи. И хотя такое различие может показаться незначи- 
тельным, не следует забывать, что умственные способности каждого человека в 
той или иной мере ограничены. Так, возня с ключевыми словами и оператора- 
ми, неохотно принимаемыми компилятором, отнимает немало вычислительной 
мощности мозга. Работа же в паре с другим разработчиком позволяет в немалой 
степени задействовать его умственные способности в процессе решения задачи. 
Как говорится, один ум хорошо, а два — лучше. 

Присущее данной методике давление со стороны коллеги в паре помогает 
преодолевать моменты слабости и бороться с дурными привычками присваи- 
вать переменным имена вроде Ёоо. Когда за вашими действиями активно на- 
блюдают, вы в меньшей степени склонны прибегать к потенциально постыдным 
ухищрениям ради достижения цели кратчайшим путем. И это также приводит в 
итоге к повышению качества программного обеспечения. 


ГРУППОВОЕ ПРОГРАММИРОВАНИЕ 


Но если два ума лучше, чем один, то не привлечь ли с десяток разных людей 
к решению одной задачи, поручив одному из них набирать исходный код на 
клавиатуре? Групповое программирование, несмотря на свое название, не под- 
разумевает толпы людей с факелами и кольями. Оно просто расширяет парное 
программирование, чтобы в совместной работе принимали участие не только 
два разработчика. Поборники данной методики сообщают о замечательных ре- 
зультатах группового решения трудных задач. В такие группы можно без особо- 
го труда ввести людей, которые не являются членами команды разработчиков, в 
том числе пользователей, спонсоров проекта и тестировщиков. 

На самом деле в нашем первом “невозможном” совместном проекте, о ко- 
тором речь шла ранее в этом разделе, мы считали привычным явлением, когда 
один из нас набирал исходный код, а другой обсуждал текущий вопрос со спе- 
циалистом в предметной области данного проекта. По существу, мы работали 
группой из трех человек. Групповое программирование можно рассматривать 
как тесное сотрудничество при активном программировании. 


Что СЛЕДУЕТ ДЕЛАТЬ? 


Если в настоящий момент вы программируете индивидуально, опробуйте 
методику парного программирования. Выделите на это как минимум две не- 
дели, по несколько часов в день, поскольку эта методика может показаться вам 


314 Глава 8 • До начала проекта 


поначалу непривычной. Для выработки новых идей в режиме мозгового штур- 
ма или решения щекотливых вопросов можно опробовать методику группового 
программирования. Если вы уже практикуете парное или групповое програм- 
мирование, то привлекаете ли вы к совместной работе только разработчиков 
или же допускаете участие в ней пользователей, спонсоров, тестировщиков и 
прочих лиц? 

Как и при всяком другом сотрудничестве, необходимо руководствоваться как 
техническими, так и человеческими особенностями. В приведенных ниже неко- 
торых рекомендациях поясняется, с чего следует начать. 


® Пишите код, не выпячивая свое “я”. Тут дело не в том, кто самый лучший, 
поскольку у каждого из нас свои достоинства и недостатки. 


• Начинайте с малого. Привлеките к совместной работе 4-5 человек или же 
начните лишь с нескольких пар, работающих вместе в течение коротких 
периодов времени. 


® Критикуйте написанный код, а не его автора. Фраза “рассмотрим этот блок 
кода” звучит намного лучше, чем фраза “ты ошибся”. 


® Внимательно слушайте, пытаясь понять чужую точку зрения. Отличие от 
вашей точки зрения еще не означает ее неправоту. 


® Почаще проводите ретроспективы, чтобы постараться работать лучше в 
дальнейшем. 


Программирование в одном и том же помещении или в удаленном режиме 
индивидуально, в парах или группах — все это эффективные методы совместной 
работы для решения насущных задач. Если вам и вашей команде приходилось 
когда-нибудь применять какой-нибудь из этих методов на практике, попробуйте 
поэкспериментировать с другими методами. Но не подходите прямолинейно к 
внедрению выбранного метода. Ведь для каждого стиля разработки имеются оп- 
ределенные правила, предположения и руководящие принципы. Например, при 
групповом программировании рекомендуется менять набирающего исходный 
код разработчика через каждые 5-10 минут. 

Почитайте литературу, а также изучите прочие материалы на данную тему, 
чтобы уяснить преимущества и недостатки каждой упоминавшейся в этом раз- 
деле методики программирования. Возможно, стоит начать с простого упраж- 
нения в программировании, а не просто сразу опробовать выбранную методику 
на самом трудном рабочем коде. Но, как бы вы ни поступили, примите к сведе- 
нию еще один завершающий совет. 


Не вникайте в исходный код в одиночку 
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СУЩНОСТЬ ГИБКОСТИ 


“Вы все еще пользуетесь этим словом, но я не думаю, 


что оно означает именно то, что вы подразумевает”. 


Иниго Монтойя? 


Прилагательное “гибкий” обозначает, как именно сделать что-нибудь. Так, 
можно быть гибким разработчиком или членом команды, в которой приняты 
нормы практики гибкой разработки, или же команды, гибко реагирующей на 
перемены и провалы. Гибкость — это ваш стиль, а не вы сами. 


Гибкость — это не существительное, а порядок 
выполнения действий 


На момент написания данной книги прошло почти двадцать лет после при- 
нятия Манифеста гибкой разработки программного обеспечения’, и с тех пор 
многие разработчики успешно применяют его ценные положения на практике. 
Мы наблюдаем немало чудесных команд, находящих способы принять ценности 
гибкой разработки и руководствоваться ими в том, что они делают и как они 
изменяют то, что делают. 

Но мы также наблюдаем и обратную сторону гибкости: явное стремление ко- 
манд и компаний к готовым решениям, где гибкость упакована в привлекатель- 
ную обертку. И многие консультанты и компании будут только рады продать 
то, что хотят их клиенты. Мы видим, что в компаниях принимается все больше 
уровней управления, формальной отчетности, узкой специализации разработ- 
чиков и должностей с забавными названиями, которые просто означают чьи-то 
обязанности следить за работой других с папкой-планшетом и хронометром?. 
И мы считаем, что многие просто утратили ясное представление об истинном 
назначении гибкости, поэтому нам хотелось бы вернуть их к основным ценнос- 
тям гибкой разработки. 

Напомним основные положения Манифеста гибкой разработки программного 


обеспечения, где перечисленные приведенные ниже ценности. 


“Мы раскрываем лучшие способы разработки программного обеспече- 
ния, выполняя ее сами и помогая делать это другим. В своей работе мы 
пришли к признанию следующих ценностей. 


5 Іпіро Мопіоуа — вымышленный персонаж романа Тйе Ргіпсеѕѕ Вгійе (Принцесса-невес- 
та) современного американского писателя Уильяма Голдмана. 


7 См. по адресу Һірѕ: / /аді1етапіѓеѕіо.ога. 


$ Подробнее о том, насколько неудачным может оказаться такой подход к разработке про- 
граммного обеспечения, см. Тйе Туғаппу оў Меітісѕ [Мий8]. 
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® Отдельные личности и взаимодействия превыше процессов и инструмен- 
тальных средств. 


ә Работоспособное программное обеспечение превыше всеобъемлющей до- 
кументации. 


е Сотрудничество с заказчиками превыше согласования контрактов. 
ё Реагирование на перемены превыше следования плану. 


Это означает, что, несмотря на ценность элементов, указанных спра- 
ва в каждом из перечисленных выше положений, мы больше ценим эле- 
менты, указанные слева”. 


Всякий, предлагающий нечто, явно повышающее важность элементов, ука- 
занных справа в каждом из положений Манифеста гибкой разработки програм- 
много обеспечения, по сравнению с элементами, указанными слева, на самом 
деле не разделяет ценности наших и авторов этого документа. А всякий, пред- 
лагающий готовое решение, просто не читал вводную часть этого документа. 
К заявленным в нем ценностям побуждает и извещает о них действие, раскры- 
вающее лучшие способы производства программного обеспечения. Это не ста- 
тический документ, а предложения относительно порождающего процесса. 


ГИБКИЙ ПРОЦЕСС ВООБЩЕ НЕВОЗМОЖЕН 


В действительности всякий раз, когда кто-нибудь говорит “сделайте это — 
и это и будет гибко”, он не прав по определению. Гибкость, как в физическом 
мире, так и в разработке программного обеспечения, — это своевременное ре- 
агирование на неизвестность и перемены, возникающие тотчас, как только вы 
приступаете к делу. Газель не бежит по прямой линии, а гимнаст каждую се- 
кунду вносит сотни корректив в свои движения, реагируя на изменения в ок- 
ружающей его среде, чтобы допустить минимум ошибок в расположении своих 
конечностей. 

Это же относится к командам и индивидуальным разработчикам. Для разра- 
ботки программного обеспечения не существует единого плана. Об этом упорно 
твердит упомянутый выше манифест и перечисленные в нем ценности, и все 
они имеют отношение к сбору ответной реакции и реагированию на нее. Эти 
ценности сообщают не о том, что нужно делать, а о том, к чему следует стре- 
миться, решившись что-то делать. 

Такие решения всегда принимаются в определенном контексте, поскольку 
они зависят от вас самих, характера вашей команды, разрабатываемого прило- 
жения, применяемых инструментальных средств, вашей организации, вашего 
заказчика, внешнего мира и невероятно большого числа других фактов, одни из 
которых более важны, чем другие. Никакой фиксированный, статический план 
действий не позволит преодолеть подобную неопределенность. 
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Что жЕ ТОГДА ДЕЛАТЬ? 


Никто не скажет вам, что нужно делать. Но мы думаем, что можем подска- 
зать вам общее направление, в котором следует двигаться к желанной цели. Все 
сводится к тому, как справиться с неопределенностью. В упомянутом выше ма- 
нифесте предлагается собирать ответную реакцию и действовать соответствен- 
но. Итак, рецепт гибкой работы состоит в следующем. 


1. Выясните, где находитесь. 
2. Сделайте наименьший значимый шаг в нужную сторону. 


3. Оцените, где вы оказались, и исправьте все, что нарушили. 


Повторяйте приведенные выше действия до тех пор, пока не завершите на- 
меченную работу. Пользуйтесь данным рецептом рекурсивно на каждом уровне 
всей своей деятельности. Иногда даже самое тривиальное на первый взгляд ре- 
шение становится важным, когда вы собираете ответную реакцию, как показано 
в приведенном ниже примере. 


“Теперь мне нужен код, чтобы получить владельца счета. 

Іе цзег = ассоппЕОмпег (ассоцп Тр); 

М-да... имя азег кажется бесполезным. Изменю-ка я его омпег. 
1еЕ омпег = ассоипЕОмпег (ассоипЕ ТО); 


Но теперь это кажется несколько избыточным. Что я на самом деле 
пытаюсь здесь сделать? В пользовательской истории говорится, что 
этому лицу следует отправить сообщение по электронной почте, по- 
этому мне нужно найти адрес его электронной почты. Может быть, 
сам владелец счета мне вообще не нужен?” 


1еЕ ема1] = епа11ОЁЕАссойипЕОмпег (ассочп ТО); 


Применив эту цепь обратной связи на довольно низком уровне именования 
переменной, мы фактически улучшили архитектуру всей системы, сократив свя- 
зывание данного фрагмента кода с фрагментом, который оперирует счетами. 

Цепь обратной связи применима и на наивысшем уровне проекта. Одна из 
наших наиболее успешных работ была сделана, когда мы приступили к прора- 
ботке требований клиента, предприняли один шаг и осознали, что все, что мы 
предполагали делать, — не нужно, и что самое лучшее решение вообще не тре- 
бовало программного обеспечения. 

Применение цепи обратной связи можно расширить за пределы одного про- 
екта. Команды должны применять ее для анализа своих процессов и того, на- 
сколько хорошо они работают. Те команды, которые не экспериментируют пос- 
тоянно со своими процессами, нельзя считать гибкими. 
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И это ДВИЖЕТ ПРОЕКТ 


В разделе “Тема 8. Сущность качественного проектирования” главы 2 “Праг- 
матичный подход” утверждалось, что мерой качества проектирования может 
служить простота изменения его результата: грамотное проектирование дает 
нечто, что изменить легче, чем при неграмотном проектировании. И в этом об- 
суждении гибкости поясняется, почему это именно так. 

Сначала вы вносите изменения, а затем обнаруживаете, что они вам не нра- 
вятся. Как пояснялось в п.3 приведенного выше рецепта, вам придется испра- 
вить все, что вы нарушили. Чтобы цепь обратной связи действовала эффективно, 
такое исправление должно быть как можно более безболезненным. В противном 
случае возникнет искушение оставить все как есть, без исправления. Подробнее 
о последствиях такого решения речь шла в разделе “Тема 3. Программная энт- 
ропия” главы 1 “Философия прагматизма”. Для того чтобы вся рассматриваемая 
здесь методика гибкой разработки оказалась пригодной, следует практиковать 
качественное проектирование, поскольку именно оно способствует простоте 
изменений. Если внести изменения нетрудно, то можно, не колеблясь, вносить 
соответствующие коррективы на каждом уровне. Это и есть гибкость. 


Другие разделы, связанные с данной темой 


® Тема 27. Не опережайте свет фар вашего автомобиля, глава 4 “Прагматич- 
ная паранойя”. 


® Тема 40. Рефакторинг, глава 7 “По ходу кодирования". 


® Тема 50. Кокосами не обойтись, в главе 9 “Прагматичные проекты’. 


Задачи 


Простая цепь обратной связи подходит не только для разработки програм- 
много обеспечения. Обдумайте другие решения, которые вам приходилось 
принимать в последнее время. Можно ли было бы их улучшить, размыш- 
ляя над тем, как бы удалось их отменить, если бы дело приняло нежела- 
тельный оборот? Можете ли вы придумать способы улучшить то, что дела- 
ете, собирая ответную реакцию и соответственно реагируя на нее? 


ГЛАВА 9 


По ходу работы над проектом разработчикам приходится отступать от воп- 
росов, связанных с индивидуальными философскими воззрениями и принципа- 
ми программирования, переходя к обсуждению более общих вопросов масштаба 
целого проекта. Мы не собираемся здесь вдаваться в особенности управления 
проектами, но все же рассмотрим ряд очень важных областей, способствующих 
удачному или неудачному завершению любого проекта. 

Как только над проектом станет работать не один человек, а команда, придет- 
ся установить ряд основных правил и поручить выполнение соответствующих 
частей проекта конкретным лицам. В разделе “Прагматичные команды” будет 
показано, как это делается с учетом прагматичной философии. 

Назначение конкретной методики разработки программного обеспечения — 
помочь людям работать вместе. Делаете ли вы и ваша команда то, что вам под- 
ходит, или же только размениваетесь на тривиальные поверхностные артефак- 
ты, не извлекая настоящих выгод для себя и своей команды? Ответы на этот 
и другие насущные вопросы разработки программного обеспечения даются в 
разделе “Кокосами не обойтись’, где раскрываются также секреты успешной ра- 
боты над проектами. 

И, разумеется, ничто из этого вообще не важно, если вы не в состоянии вы- 
пускать программное обеспечение согласованно и надежно. А этому способс- 
твует волшебная троица: контроль версий и тестирование исходного кода, а так- 
же автоматизация процесса разработки, как поясняется в разделе “Начальный 
набор инструментальных средств программиста-прагматика”. 

В конечном счете успешность завершения проекта оценивается с точки зре- 
ния его спонсора. И здесь важно понимать, что значение имеет прежде всего 
восприятие успеха. Поэтому в разделе “Доставляйте своим пользователям удо- 
вольствие” показывается, как удовлетворить каждого спонсора проекта. 

Последний совет, приведенный в данной книге, является прямым следствием 
всех остальных советов. В разделе “Гордость и предубеждение” поясняется, как 
сдавать проект заказчику на подпись с гордостью за проделанную работу. 
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ПРАГМАТИЧНЫЕ КОМАНДЫ 


“В группе Г Штоффель надзирает за шестью 
первоклассными программистами. 

Трудности руководства ими можно грубо сравнить 
с выпасом выводка котов”. 


Иа теоп Ро5{ Мадагіпе от 9 июня 1985 г. 


Даже в 1985 году шутка по поводу выпаса выводка котов считалась уста- 
ревшей. А ко времени выхода в свет первого издания данной книги под конец 
столетия она вообще стала анахронизмом, хотя до сих пор остается расхожей, 
поскольку в ней есть доля правды. Программисты действительно похожи чем-то 
на котов: они образованы, своевольны, самоуверенны, независимы и зачастую 
прославлены в сети. 

В этой книге до сих пор рассматривались прагматичные методики, помога- 
ющие отдельным программистам стать лучше. Могут ли эти методики приго- 
диться командам, пусть даже состоящим из своевольных и независимых людей? 
Однозначно могут! Преимущества быть прагматичным программистом много- 
кратно усиливаются, когда программист работает в прагматичной команде. 

На наш взгляд, команда — это небольшая, самостоятельная и в основном ус- 
тойчивая организационная единица. Пятьдесят людей — это не команда, а тол- 
па'. Команды, члены которых постоянно привлекаются к выполнению чужих 
заданий и не знают друг друга, вообще не считаются командами. Они похожи на 
незнакомых людей, временно столпившихся под козырьком автобусной останов- 
ки в дождливый день. 

Прагматичная команда невелика и состоит не более, чем из 10-12 человек, ко- 
торые редко приходят и уходят. Все хорошо знакомы и полагаются друг на друга. 


Поддерживайте небольшие, устойчивые команды 


В этом разделе будет вкратце показано, как применять прагматичные мето- 
дики к командам в целом. Приведенные здесь заметки служат лишь отправной 
точкой. Как только образуется группа прагматичных разработчиков, работаю- 
щих в благоприятных условиях, они быстро выработают и уточнят пригодную 
для них динамику работы в команде. Итак, изложим материал предыдущих глав 
иначе с точки зрения команд. 


1 По мере увеличения численного состава команд связи между программистами растут 
со скоростью О(и?), где п — число членов команды. В крупных командах связь начинает 
ослабевать и становится неэффективной. 
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НикАКИХ РАЗБИТЫХ ОКОН 


Качество — это дело всей команды. Даже самому прилежному разработчику, 
работающему в беспечной команде, будет трудно поддерживать свой энтузиазм, 
необходимый для решения пустячных задач. Трудности еще больше усугубляют- 
ся, если команда активно отговаривает такого разработчика не тратить время 
на такие пустяки. 

Команды в целом не должны мириться с разбитыми окнами, т.е. с теми мел- 
кими несовершенствами, которые некому устранить. Команда обязана взять на 
себя ответственность за качество разрабатываемого ею программного продук- 
та, поддерживая тех разработчиков, которые ясно понимают принцип “никаких 
разбитых окон”, описанный в разделе “Тема 3. Программная энтропия” главы 1 
“Философия прагматизма”, а также помогая уяснить данный принцип тем, кто 
еще не открыл его для себя. 

В некоторых командных методологиях предусматривается “ответственный за 
качество’, которому команда поручает отвечать за качество выпускаемого про- 
граммного продукта. Но это нелепо, поскольку качество может быть достигнуто 
лишь в результате индивидуального вклада всех членов команды. Качество за- 
кладывается как основание, а не прикрепляется болтами. 


СВАРЕННЫЕ ЛЯГУШКИ 


Помните, как в разделе “Тема 4. Суп из камней и вареные лягушки” главы 1 
“Философия прагматизма” упоминалось о вымышленной лягушке в кастрюле с 
водой? Она не замечает постепенное изменение своего окружения и в конечном 
итоге оказывается сваренной. То же самое может произойти и с отдельными 
людьми, потерявшими бдительность. Ведь не так-то просто следить за всем ок- 
ружением в самый разгар работы над проектом. 

Команды могут очень легко свариться целиком, как лягушки. Ее члены могут 
посчитать, что возникший вопрос должен решить кто-то другой, а отвечать за 
внесение запрашиваемого пользователем изменения должен руководитель ко- 
манды. И даже команды с наилучшими намерениями могут предавать забвению 
существенные изменения в своих проектах. 

С подобными явлениями следует бороться, поощряя всех членов команды 
активно и постоянно контролировать изменения в окружающей их среде. Необ- 
ходимо быть начеку, следя за расширением рамок проекта, сокращением сроков 
выполнения работ, внедрением дополнительных функциональных возможнос- 
тей, появлением новых сред — другими словами, за всем, что первоначально 
не было ясно и понятно. Кроме того, необходимо следить за количественными 
показателями новых требований". Команда не должна отвергать изменения с по- 


2 Для этой цели диаграмма выгорания подходит лучше, чем диаграмма сгорания. Пользу- 
ясь диаграммой выгорания, можно ясно видеть, как дополнительные функциональные 
средства меняют цели и намерения по ходу проекта. 
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рога, а должна осознавать, что они все равно происходят. В противном случае 
она рискует свариться в кипящей воде, как лягушка. 


ПЛАНИРОВАНИЕ ПОПОЛНЕНИЯ БАГАЖА ЗНАНИЙ 


В разделе “Тема 6. Ваш багаж знаний” главы 1 “Философия прагматизма” 
были рассмотрены способы своевременного пополнения багажа индивидуаль- 
ных знаний. Команды, стремящиеся к успеху, должны анализировать и попол- 
нять багаж своих знаний и умений. 

Если ваша команда серьезно относится к усовершенствованиям и нововве- 
дениям, их следует планировать. Попытка сделать что-нибудь, когда настанет 
удобный момент, означает, что это не произойдет никогда. С каким бы видом за- 
дела, списка задач или порядка работ ни приходилось иметь дело, его не следует 
откладывать на будущую стадию разработки. Ведь команда работает не только 
над новыми функциональными средствами. Ниже перечислены некоторые из 
возможных путей пополнения командой своего багажа знаний. 


® Сопровождение прежних систем. Несмотря на то что всем нравится ра- 
ботать в новой с иголочки системе, вполне возможно, что придется пора- 
ботать и над сопровождением старой системы. Нам встречались команды, 
пытавшиеся отложить такую работу в долгий ящик. Если команда обязана 
выполнять такие задачи, она должна выполнять их точно и в срок. 


• Обсуждение и уточнение процессов. Непрерывное совершенствование 
может происходить только в том случае, если есть время оглянуться и 
выяснить, что работает и что не работает, а затем внести необходимые 
изменения (см. раздел “Тема 48. Сущность гибкости” главы 8 “До начала 
проекта”). Слишком много команд оказываются настолько занятыми вы- 
черпыванием воды из тонущей лодки, что не имеют времени на устране- 
ние течи. Планируйте работы по выявления и устранению неполадок. 


• Экспериментирование с новыми технологиями. Не внедряйте новые 
технологии, каркасы или библиотеки только потому, что это делают все, 
или же на основании увиденного на конференции либо прочитанного в 
Интернете. Технологии, претендующие на внедрение, следует проверять с 
помощью прототипов. Поставьте соответствующие задачи в график вы- 
полнения работ, опробуйте новые технологии и проанализируйте получен- 
ные результаты. 


• Обучение и совершенствование навыков. Личное обучение и совершенс- 
твование навыков служит отличной отправной точкой, хотя многие навы- 
ки оказываются более эффективными, если применяются на уровне ко- 
манды. Планируйте подобные мероприятия, будь то в виде неформальных 
встреч или более формальных учебных занятий. 
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Планируйте и воплощайте в жизнь пополнение багажа знаний 


ВНЕШНЕЕ ОБЩЕНИЕ КОМАНДЫ 


Очевидно, что разработчики могут общаться друг с другом в своей команде. 
Свои рекомендации по поводу того, как облегчить общение, мы дали в разделе 
“Тема 7. Общайтесь!” главы 1 “Философия прагматизма”. Но при этом очень лег- 
ко забыть, что команда сама присутствует в конкретной организации. Поэтому, 
как организационная единица, команда должна свободно общаться с остальным 
миром. 

Для посторонних наихудшими являются замкнутые и скрытные проектные 
команды. Они проводят совещания без всякого порядка, и на них никто не хо- 
чет говорить. Их обмен сообщениями по электронной почте и проектные доку- 
менты беспорядочны: у них нет двух одинаковых документов и единой употреб- 
ляемой терминологии. 

Хорошие проектные команды заметно отличаются своей индивидуальнос- 
тью. Другие люди стремятся встретиться с такими командами на совещаниях, 
поскольку они знают, что придут на хорошо подготовленное мероприятие, где 
все участники чувствуют себя уютно. Такие команды составляют ясную, точную 
и согласованную документацию и говорят одним голосом*. У них даже может 
быть чувство юмора. 

Имеется простой маркетинговый прием, помогающий командам общаться как 
единое целое. Он состоит в том, чтобы сформировать фирменный стиль. Начи- 
ная проект, придумайте ему подходящее название — в идеальном случае взяв его 
с потолка. (В прошлом мы называли свои проекты, например, попугаями-убий- 
цами, охотящимися на овец, разными оптическими иллюзиями, песчанками, 
персонажами мультфильмов и мифическими городами.) Уделите полчаса, чтобы 
придумать забавный логотип, а затем воспользуйтесь им в своем проекте. На 
первый взгляд, такая рекомендация кажется нелепой, но на самом деле она дает 
вашей команде возможность создать свою индивидуальность, а окружающему 
миру — запомнить нечто, связанное с вашей работой. 


НЕ ПОВТОРЯЙТЕСЬ 


В разделе “Тема 9. ОКУ — пороки дублирования” главы 2 “Прагматичный 
подход” речь шла о том, как трудно исключить дублирование работы отдельны- 
ми членами команды. Такое дублирование приводит к напрасным затратам тру- 


? Команда говорит одним голосом с внешним миром; внутри команды настоятельно ре- 
комендуется проводить живые, активные дебаты. Ведь грамотные разработчики обычно 
относятся весьма ревностно к своей работе. 
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да и способно превратить сопровождение программного обеспечения в сущий 
кошмар. В тех командах, где это происходит, зачастую проектируются разроз- 
ненные системы, у которых мало общего, но много дублирующихся функцио- 
нальных возможностей. 

Хорошо налаженное общение в команде служит главным средством, помога- 
ющим избежать подобных осложнений. Под фразой “хорошо налаженное” здесь 
понимается мгновенное и свободное общение без всяких трений. Это означает 
возможность задать членам команды вопрос и почти мгновенно получить ответ. 
Так, если команда совместно размещается в одном месте, для этого достаточно 
высунуть голову из своей кабинки или в коридор. В командах, работающих в 
удаленном режиме, возможно, придется полагаться на систему обмена сообще- 
ниями или другие электронные средства. 

Если вам приходится целую неделю ждать совещания в команде, чтобы за- 
дать вопрос или поделиться положением своих дел, это может вызвать немало 
трений“. Свободное общение без всяких трений означает простую и нецере- 
монную атмосферу в команде, позволяющую задавать вопросы, делиться своими 
достижениями и затруднениями, открытиями и знаниями, а также оставаться в 
курсе того, что делают ваши коллеги. Поддерживайте свою осведомленность обо 
всем, что происходит в команде, чтобы соблюдать принцип ОКУ. 


ТРАССИРУЮЩИЕ ПУЛИ В КОМАНДЕ 


Проектной команде приходится выполнять много разных заданий в различ- 
ных областях проекта, касающихся самых разных технологий. Для этого необ- 
ходимо уяснить исходные требования, спроектировать архитектуру, запрограм- 
мировать и протестировать клиентскую и серверную части разрабатываемой 
системы. Существует типичное недопонимание, состоящее во мнении, что эти 
виды деятельности и задания можно выполнять по отдельности и обособлен- 
но, — хотя в действительности делать этого нельзя. 

Некоторые методологии поддерживают самые разные роли и должности в 
команде или создание совершенно отдельных специализированных команд. Но 
недостаток такого подхода заключается в том, он вносит шлюзы и сдачи. И тогда 
вместо плавного перехода от разработки к развертыванию образуются искусст- 
венные шлюзы, где работа команды останавливается. А сдачи работ вынуждены 
ждать своего приема, утверждения, бумажной волокиты. Бережливые люди на- 
зывают это расточительством и поэтому стремятся активно исключить его. 

Все эти разные роли и виды деятельности фактически являются разными 
представлениями одной и той же задачи, и поэтому их искусственное разделе- 
ние может вызвать немало хлопот. Например, те программисты, которые отде- 
лены двумя или тремя уровнями от фактических пользователей написанного 


* Энди встречались команды, проводившие свои “ежедневные” летучки по пятницам. 
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ими кода, вряд ли понимают контекст, в котором используются результаты их 
трудов. В итоге они не могут принимать обоснованные решения. 

Мы рекомендуем пользоваться методом трассирующих пуль (см. раздел 
“Тема 12. Трассирующие пули” главы 2 “Прагматичный подход”), разрабатывая 
отдельные, пусть небольшие и первоначально ограниченные функциональные 
средства, которые проходят сквозь всю систему. И для этого потребуются все 
ваше умение и опыт, чтобы применить данный метод в команде, где всем ее 
членам (проектировщику СІ и взаимодействия с пользователем, администра- 
тору базы данных, контролеру качества и прочим) удобно и привычно работать 
вместе. Применяя метод трассирующих пуль, можно довольно быстро реали- 
зовать очень мелкие фрагменты функциональных средств, чтобы немедленно 
получить ответную реакцию, позволяющую судить, насколько хорошо команда 
взаимодействует и доставляет результаты своих трудов. Благодаря этому созда- 
ется среда, в которой можно быстро и просто вносить изменения и настраивать 
команду и процесс разработки. 


Организовывайте полнофункциональные команды 


Создавайте команды таким образом, чтобы разрабатывать код комплексно, 
постепенно и итерационно. 


АВТОМАТИЗАЦИЯ 


Чтобы обеспечить согласованность и точность, лучше всего автоматизи- 
ровать все, что делает команда. Зачем, например, разбираться со стандартами 
форматирования кода, если текстовый редактор или интегрированная среда раз- 
работки может сделать это автоматически? Зачем проводить тестирование вруч- 
ную, если это можно делать автоматически в процессе непрерывной сборки: 
Наконец, зачем выполнять развертывание вручную, если этот процесс можно 
автоматизировать, чтобы надежно повторять его всякий раз, когда в этом воз- 
никнет потребность: 

Автоматизация является существенной составляющей работы каждой про- 
ектной команды. Поэтому следует позаботиться о том, чтобы у команды было 
достаточно навыков комплектации инструментальных средств для построения 
и развертывания инструментальных средств, автоматизирующих разработку 
проектов и развертывания в условиях эксплуатации. 


ЗНАЙТЕ, КОГДА ОСТАНОВИТЬСЯ 


Помните, что команды состоят из индивидуальностей. Дайте каждому члену 
возможность проявить себя, а также обеспечьте их поддержу и возможность 
вклада в проект. И тогда вам останется лишь бороться с искушением нанести 
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еще немного краски, как художнику, упоминавшемуся в разделе “Тема 5. Подхо- 
дящее программное обеспечение” главы 1 “Философия прагматизма”. 


Другие разделы, связанные с данной темой 


Тема 2. Кот съел мой исходный код, глава 1 “Философия прагматизма”. 
Тема 7. Общайтесь!, глава 1 “Философия прагматизма”. 

Тема 12. Трассирующие пули, глава 2 “Прагматичный подход”. 

Тема 19. Контроль версий, глава 3 “Основные инструментальные средства". 
Тема 50. Кокосами не обойтись. 


Тема 51. Начальный набор инструментальных средств программиста-праг- 
матика. 


Задачи 


Поищите успешные команды вне области разработки программного обес- 
печения. В чем причина их успешности? Пользуетесь ли вы какими-нибудь 
процессами, обсуждавшимися в этом разделе? 


Приступая к проекту в следующий раз, попытайтесь убедить его участни- 
ков сформировать свой особый фирменный стиль. Дайте своей организа- 
ции время привыкнуть к этой идее, а затем проведите быструю проверку, 
чтобы выяснить, какие отличия внес новый фирменный стиль как в самой 
команде, так и за ее пределами. 


Вам, вероятно, приходилось решать задачи вроде следующей: “Если четы- 
рем рабочим требуется шесть часов, чтобы вырыть канаву, то сколько вре- 
мени для этого потребуется восьми рабочим?” Но какие реальные факты 
могут повлиять на решение подобной задачи, если речь идет не о рабочих, 
а о программистах? И сколько имеется вариантов фактически сократить 
время выполнения подобной работы? 


Прочитайте книгу Фредерика Брукса Тйе Муса! Мап Мопй (Мифиче- 
ский человеко-месяц) [Вго96]. В качестве дополнительного задания приоб- 
ретите два экземпляра этой книги, чтобы читать ее в два раза быстрее. 


О О ОООО 936909 099939090905656>1 0600Ж 55 . ела до и зле да мо то мае ат аа ср СЕ 


Кокосдми НЕ ОБОЙТИСЬ 


Туземные обитатели одного острова никогда не видели прежде самолет и не 
встречались с прилетевшими на нем чужеземцами. В обмен на право пользо- 
ваться их землей чужеземцы предоставили островитянам возможность наблю- 
дать за этими механическими птицами, которые целый день то прилетали, то 
улетали со “взлетной полосы”, принося на их родной остров невероятные мате- 
риальные ценности, иногда перепадающие туземцам. Чужеземцы упоминали о 
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чем-то вроде войны и сражения. Однажды все это кончилось тем, что чужезем- 
цы покинули остров, прихватив с собой свои чудесные богатства. 

Отчаянно пытаясь вернуть подарок судьбы, островитяне восстановили ко- 
пию аэродрома с диспетчерской вышкой и прочим оборудованием, используя 
местные материалы: лианы, скорлупы кокосового ореха, пальмовые ветки и т.п. 
Но по какой-то непонятной им причине самолеты не прилетали, несмотря на то, 
что островитяне все расставили по своим местам. А дело в том, что они сыми- 
тировали форму, а не содержание. Антропологи называют это карго-культом. 

Разработчики программного обеспечения слишком часто оказываются в 
роли этих незадачливых островитян. Ведь очень легко попасться в западню 
карго-культа, вложив средства и труд в построение чисто внешней имитации, 
надеясь вызвать скрывающиеся под ней волшебные силы, способные привести 
ее в действие. Но, как и в первобытных карго-культах Меланезии?, бутафорский 
аэродром, построенный из скорлупы кокосовых орехов, не может заменить со- 
бой настоящий аэропорт. 

Нам, например, приходилось лично встречаться с командами, заявлявшими, 
будто бы они пользуются методикой $сгат в своей работе. Но при более внима- 
тельном рассмотрении оказалось, что они проводили стоя ежедневные летучки 
лишь один раз в неделю, а четырехнедельные повторяющиеся циклы нередко 
превращались у них в шести- и даже восьминедельные циклы. Они считали это 
нормальным, поскольку пользовались весьма распространенным инструмен- 
тальным средством “гибкого” планирования работ. На самом же деле они вкла- 
дывали средства и труд лишь в искусственные артефакты, суеверно твердя как 
заклинание такие термины, как “летучка” или “итерация”. Не удивительно, что 
им не удавалось вызвать к жизни по-настоящему волшебные силы. 


ВСЕ ДЕЛО В КОНТЕКСТЕ 


Приходилось ли вам или вашей команде попадать в подобную западню: 
Спросите себя: почему вы вообще пользуетесь данной конкретной методикой 
разработки, каркасом, библиотекой или методикой тестирования? Действитель- 
но ли все это подходит для выполнения текущего задания и вам лично? А может 
быть, все это было принято лишь потому, что применялось в каком-нибудь не- 
давнем проекте, история успеха которого была почерпнута из Интернета? 

Ныне наблюдается тенденция внедрять у себя правила и процессы таких ус- 
пешных компаний, как $роѓіѓу, Мех, Ѕїгіре, СИГаь и пр. У каждой из них свой 
взгляд на разработку программного обеспечения и руководство ею. Но давайте 
рассмотрим контекст: разве вы работаете на тот же рынок, с теми же ограниче- 
ниями и возможностями, имеете аналогичный опыт и масштабы организации, у 
вас аналогичные подходы к руководству и такая же культура, пользовательская 
база и требования: 


5 См. по адресу ПЕЕрз: //ги.и1К1реа1а.ога/м1К1 / Карго-культ. 
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Не попадайтесь на эту удочку! Определенных артефактов, внешних структур, 
правил, процессов и методов явно недостаточно. 


Делайте то, что пригодно, а не то, что модно 


А как узнать, что именно пригодно? Для этого достаточно воспользоваться 
одним из самых основных прагматичных приемов, а именно: 

Пробуйте! 

Опробуйте саму идею в небольшой команде или ряде команд. Оставьте то, 
что годится, и откажитесь от всего остального как расточительства или наклад- 
ных расходов. Никто не сможет принизить вашу организацию только потому, 
что она действует иначе, чем компании $роќіѓу или Ме, и не следует приня- 
тым в них процессам, которые способствовали их успешному росту. Ведь через 
несколько лет эти компании, созрев, упрочившись и продолжая расти дальше, 
станут в очередной раз делать нечто иное. Именно в этом и кроется секрет их 
успеха. 


Один И тот ЖЕ ПОДХОД ГОДИТСЯ НЕ ВСЕМ 


Назначение методологии разработки программного обеспечения — помочь 
разработчикам работать вместе. Как пояснялось в разделе “Тема 48. Сущность 
гибкости” главы 8 “До начала проекта’, не существует единого плана, которого 
можно придерживаться, разрабатывая программное обеспечение, и особенно 
того плана, который был составлен кем-то чужим в другой организации. 

Многие обучающие программы на самом деле оказываются еще хуже, пос- 
кольку они основываются на способностях учащихся запоминать и соблюдать 
правила. Но вам требуется совсем не это, а способность видеть дальше сущест- 
вующих правил и выгодно пользоваться имеющимися возможностями. Это сов- 
сем иной образ мышления, чем мнение вроде “так принято в методике Ѕсгит, 
Геап, Капђап, экстремального программирования, гибкой разработки...” и т.д. 

Вместо этого следует взять все самое лучшее из любой методологии и при- 
способить к применению в своей практике. Не существует такого единого под- 
хода, который годился бы всем. Современные методы разработки программного 
обеспечения далеки от совершенства, и поэтому вам придется рассмотреть не 
только один широко распространенный метод. Например, в методике $ спит оп- 
ределяется ряд норм практики управления проектами, но сама эта методика не 
может служить достаточным руководством к действию команд на техническом 
уровне или же на уровне портфеля заказов либо организации управления для 
высшего руководства. Так с чего же начать? 
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Нам часто приходится слышать, как начальство, руководящее разработкой 
программного обеспечения, говорит своим подчиненным: “Мы должны дей- 
ствовать как Мех” (или одна из ведущих компаний в данной отрасли). Ра- 
зумеется, вы могли бы это сделать, но прежде вам пришлось бы установить 
несколько сотен серверов и привлечь десятки миллионов пользователей... 


ГЛАВНАЯ ЦЕЛЬ 


Безусловно, главная цель состоит не в том, чтобы действовать по методике 
Ѕсгит, Геап, “гибко” или по иной выбранной вами методологии разработки про- 
граммного обеспечения, а также иметь все необходимые возможности, чтобы 
выпускать работоспособное программное обеспечение, дающее пользователям 
новые возможности уже теперь, а не через недели, месяцы или годы. Многим 
командам и организациям непрерывная поставка программного обеспечения 
кажется слишком возвышенной, недостижимой целью, особенно если они об- 
ременены процессом, ограничивающим поставку месяцами или даже неделями, 
как показано ниже. Но какова бы ни была конечная цель, самое главное — по- 
стоянно двигаться в правильном направлении. 


} 
| 
| 
| 
Годы \ 
5 і 
Е | 

СЗ ЧӘР ' О аль АЕ А Аса а аан ОАЕ НЕЛЕ 
о | | 
Е | ] 
х Недели | , 
5 і | ! 
с) | | | 
| | | 

АНИ о К ИЕН 
{ І [ 
| І ! 
} | | 
Часы | ! | 
| | | 
3 | | 
| І | 

НЕВА ОБО НАК УАРВЕКААНОЯ КОНАЛИИАСАНАНР НС ЗЕБИКАН СААРА ААО РАВА ОМИ ТОН АНЕ ААСО 
і | 

Многомесячные/ ,‚ Фиксировано Непрерывная 
годовые короткие поставка 
повторяющиеся ' повторяющиеся | 
циклы (водопадная циклы (методика 
методика) Ѕсгит) 


Если программное обеспечение выпускается годами, можно попытаться со- 
кратить данный цикл до месяцев, а затем до недель. Если же применяется мето- 
дика четырехнедельных спринтов, их можно сократить до двух недель, а затем 
до одной недели и даже ежедневных выпусков. Наконец, поставки программно- 
го обеспечения можно делать по требованию. Следует, однако, иметь в виду, 
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что возможность выпускать программное обеспечение по требованию совсем 
не означает, что это необходимо делать ежеминутно каждый день. В этом режи- 
ме программное обеспечение поставляется именно тогда, когда оно требуется 
пользователям и когда это экономически целесообразно. 


Выпускайте программное обеспечение, 
когда оно требуется пользователям 


Чтобы перейти к такому стилю непрерывной разработки программного обес- 
печения, необходимо создать довольно устойчивую инфраструктуру, как обсуж- 
дается далее в разделе “Тема 51. Начальный набор инструментальных средств 
программиста-прагматика” При этом разработка ведется в главном стволе сис- 
темы контроля версий исходного кода, а не в ее ветвях, а также применяются 
такие методики, как переключатели функциональности, дающие возможность 
выборочно включать средства тестирования для пользователей. 

Как только инфраструктура будет приведена в должный порядок, необходи- 
мо решить, каким образом организовать работу. Начинающим командам, воз- 
можно, придется выбрать сначала методику $сгат для управления проектом, а 
затем технические нормы практики экстремального программирования. А более 
опытные и дисциплинированные команды могут остановить свой выбор на ме- 
тодиках КапБап и Геап, пригодных для управления как отдельными командами, 
так и более крупными организационными единицами. 

Но вместо того чтобы верить нам на слово, исследуйте и опробуйте все эти 
методики сами. И будьте внимательны, чтобы не переусердствовать. Слепо пола- 
гаясь на любую конкретную методологию, можно просто не заметить альтерна- 
тив. Привыкнув пользоваться какой-то одной методикой, вам будет очень труд- 
но заметить любые другие. Утвердившись в ней, вы не сможете быстро внедрить 
ничего другого. И тогда ничего не останется, как воспользоваться кокосами. 


Другие разделы, связанные с данной темой 


® Тема 12. Трассирующие пули, глава 2 “Прагматичный подход”, 


ә Тема 27. Не опережайте свет фар вашего автомобиля, глава 4 “Прагматич- 
ная паранойя”. 


® Тема 48. Сущность гибкости, глава 8 “До начала проекта”. 
ә Тема 49. Прагматичные команды. 


® Тема 51. Начальный набор инструментальных средств программиста-праг- 
матика. 
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НАЧАЛЬНЫЙ НАБОР ИНСТРУМЕНТАЛЬНЫХ 
СРЕДСТВ ПРОГРАММИСТА-ПРАГМАТИКА 


“Цивилизация развивается, 
расширяя количество важных операций, 
которые можно выполнять, не задумываясь”. 


Альфред Норт Уайтхед® 


В те времена, когда автомобили считались редкостью, инструкции по запус- 
ку двигателя автомобиля модели Еога Т занимали больше двух страниц. Для 
запуска двигателя современных автомашин достаточно нажать одну кнопку, и 
вся процедура запуска будет выполнена автоматически и безопасно. Водитель, 
следующий инструкции, мог залить двигатель топливом, тогда как автоматичес- 
кое пусковое устройство этого просто не допустит. 

Несмотря на то что разработка программного обеспечения все еще находит- 
ся на стадии, сравнимой с производством автомобилей модели Ео!А Т, мы не 
можем себе позволить обращаться к двухстраничным инструкциям всякий раз, 
когда требуется выполнить какую-нибудь типичную операцию. Такая операция, 
будь то процедура сборки и выпуска, тестирование, составление проектной до- 
кументации или любая другая задача, повторяющаяся по ходу проекта, должна 
быть автоматизирована на всякой машине, где ее можно повторить. 

Кроме того, требуется обеспечить согласованность и повторяемость опера- 
ций в проекте. Ведь ручные процедуры оставляются на волю случая. Их пов- 
торяемость не гарантируется, особенно если порядок выполнения процедуры 
может по-разному интерпретироваться разными людьми. 

После выхода в свет первого издания данной книги у нас возникла потреб- 
ность написать больше книг, помогающих командам разрабатывать качествен- 
ное программное обеспечение. И мы решили начать все с самого начала, т.е. 
с самых основных и важных элементов, которые требуются каждой команде не- 
зависимо от применяемой методологии, языка программирования или комплек- 
са технологий. И тогда у нас зародилась идея начального набора инструменталь- 
ных средств программиста-прагматика, охватывающая следующие три крайне 
важные и взаимосвязанные темы. 


ә Контроль версий. 
® Регрессионное тестирование. 


® Полная автоматизация. 


6 АНтед Моћ УЪиеКеа4 — британский математик, логик, философ ХХ века. — Примеч. пер. 
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На эти три столпа опирается всякий проект. Ниже поясняется, каким обра- 
зом это происходит. 


ВЕДЕНИЕ ПРОЕКТА ПУТЕМ КОНТРОЛЯ ВЕРСИЙ 


Как упоминалось в разделе “Тема 19. Контроль версий” главы 3 “Основные 
инструментальные средства’, все, что требуется для построения проекта, долж- 
но постоянно находиться под системой контроля версий исходного кода. И этот 
принцип становится еще более важным в контексте самого проекта. 

Прежде всего, это позволяет избавиться от сборочных машин. Вместо одной 
видавшей виды машины в углу помещения, к которой все боятся прикоснуться, 
как к священной корове’, сборочные машины или их кластеры могут создавать- 
ся по требованию как точечные экземпляры в “облаке” Конфигурирование раз- 
вертывания также должно находиться под контролем версий, чтобы все стадии 
от выпуска до ввода в эксплуатацию выполнялись автоматически. И при этом 
очень важно подчеркнуть, что на уровне проекта контроль версий приводит в 
действие процесс сборки и выпуска. 


Пользуйтесь контролем версий, чтобы проводить сборки, 
тесты и выпуски 


Это означает, что сборка, тестирование и развертывание запускается пос- 
редством операций фиксации или продвижения в системе контроля версий, а 
также размещения в контейнере, находящемся в “облаке”. Все стадии от выпуска 
до размещения или ввода в эксплуатацию обозначаются отдельными маркерами 
в системе контроля версий. И тогда выпуски становятся намного менее церемо- 
ниальными частями повседневной деятельности, способствуя непрерывной пос- 
тавке, не привязанной ни к одной из вычислительных машин: как сборочных, 
так и разработчиков. 


(СТРОГОЕ И НЕПРЕРЫВНОЕ ТЕСТИРОВАНИЕ 


Многие разработчики тестируют мягко, подсознательно зная, где будет на- 
рушен исходный код, и при этом избегая слабых мест в нем. Но программис- 
ты-прагматики поступают иначе. Ими движет стремление обнаружить програм- 
мные ошибки сейчас, чтобы не быть пристыженными другими, обнаружившими 
их ошибки впоследствии. 

Обнаружение ошибок похоже на рыбалку с сетью. Мы используем тонкие, 
небольшие сети (юнит-тесты), чтобы поймать пескарей, и большие, грубые сети 
(тесты интеграции) для ловли акул-убийц. Иногда рыбе удается уйти, поэтому мы 
чиним и латаем любые отверстия, которые находим, в надежде поймать все боль- 
ше и больше скользких дефектов которые плавают в нашем бассейне-проекте. 


А Мы убеждались в этом воочию больше раз, чем вы могли бы подумать. 
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Тестируйте как можно раньше, чаще и автоматически 


Тестирование исходного кода необходимо начинать как можно раньше. Ведь 
программные ошибки имеют скверную привычку очень быстро вырастать из 
мелкой рыбешки в гигантских акул-людоедов, выловить которые будет намного 
труднее. Поэтому программисты-прагматики пишут модульные тесты, причем 
в большом количестве. 

В действительности качественно разрабатываемый проект отличается тем, 
что в нем больше тестового, чем рабочего кода. Время и труд, затраченные на 
создание тестового кода, того стоят. В долгосрочной перспективе это будет об- 
ходиться намного дешевле, а у вас появится возможность производить програм- 
мные продукты практически без изъянов. Кроме того, зная, что тест прошел, вы 
обретаете большую степень уверенности в готовности проверенного фрагмента 
кода к эксплуатации. 


Программирование нельзя считать завершенным 
до тех пор, пока не пройдут все тесты 


При автоматической сборке выполняются все имеющиеся тесты. При этом 
очень важно стремиться тестировать “по-настоящему”. Это означает, что среда 
тестирования должна как можно более точно соответствовать среде эксплуата- 
ции, поскольку любые расхождения служат местом для размножения програм- 
мных ошибок. 

Сборка может охватывать несколько важных видов тестирования програм- 
много обеспечения: модульное и интеграционное, проверку на достоверность и 
верификацию, а также тестирование производительности. Этот перечень видов 
тестирования ни в коем случае не следует считать исчерпывающим, поскольку 
в некоторых специализированных проектах могут потребоваться и другие раз- 
новидности тестирования. Тем не менее данный перечень видов тестирования 
может послужить неплохой отправной точкой. 


Модульное тестирование 


Модульный тест содержит код, проверяющий отдельный модуль, как пояс- 
нялось в разделе “Тема 41. Тестировать, чтобы кодировать” главы 7 “По ходу 
кодирования’. Модульное тестирование служит основанием для всех осталь- 
ных форм тестирования, рассматриваемых в этом разделе. Если отдельные час- 
ти программы не работают по отдельности, они не будут работать и вместе. 
Поэтому все используемые модули должны пройти все свои модульные тесты, 
прежде чем вы сможете продолжить работу над проектом. 
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Как только все относящиеся к проекту модули пройдут модульные тесты, 
можно перейти к следующей стадии проекта. При этом необходимо проверить, 
каким образом все модули используются и взаимодействуют в системе. 


Интеграционное тестирование 


Результаты интеграционного тестирования показывают, насколько в рамках 
текущего проекта хорошо работают и взаимодействуют основные подсистемы. 
Так, если контракты правильно расставлены по местам и тщательно проверены, 
любые трудности интеграции могут быть легко обнаружены. В противном слу- 
чае интеграция становится благодатной почвой для размножения программных 
ошибок. В действительности интеграция зачастую оказывается единственным и 
самым крупным источником программных ошибок в системе. Интеграционное 
тестирование на самом деле служит лишь расширением описанного выше мо- 
дульного тестирования, поскольку в данном случае только проверяется, каким 
образом во всех подсистемах в целом учитываются их контракты. 


Проверка на достоверность и верификация 


Как только у вас появится выполняемый пользовательский интерфейс или 
его прототип, вам придется найти ответ на следующие очень важные вопросы: 
пользователи сообщили вам свои пожелания, но действительно ли это именно 
то, что им нужно? Соответствуют ли их пожелания функциональным требова- 
ниям к системе? И это также следует проверить. От бездефектной системы, даю- 
щей отрицательные ответы на эти вопросы, вряд ли будет много проку. Следует 
здраво оценивать схемы доступа конечных пользователей, а также их отличия 
от тестовых данных разработчиков (вспомните, например, историю с мазками 
кистью, поведанную в разделе “С чего начинать отладку” главы 3 “Основные 
инструментальные средства”). 


Тестирование производительности 


Тестирование производительности и тестирование под предельной нагрузкой 
может также оказаться очень важной стадией работы над проектом. Спроси- 
те себя: соответствует ли программное обеспечение требованиям производи- 
тельности в реальных условиях с предполагаемым числом пользователей, со- 
единений или транзакций в секунду и допускает ли оно масштабирование? Для 
тестирования некоторых приложений может потребоваться специализирован- 
ное испытательное оборудование или программное обеспечение, позволяющее 
правдоподобно сымитировать нагрузку. 


Тестирование тестов 


Если нельзя написать идеальное программное обеспечение, то нельзя так- 
же написать и идеальные тесты, поэтому необходимо проверять сами тесты. 
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В этой связи наборы тестов следует рассматривать как тщательно продуманную 
систему безопасности, призванную вовремя предупреждать о появлении про- 
граммной ошибки. Насколько лучше протестировать систему безопасности, чем 
пытаться взломать ее? Как только вы напишете тест для выявления конкретной 
программной ошибки, вызовите ее намеренно и убедитесь, что тест предупре- 
дит о ней. Этим гарантируется, что тест отловит программную ошибку, если она 
действительно произойдет. 


Пользуйтесь саботажем для проверки своих тестов 


Если вы по-настоящему серьезно относитесь к тестированию, сделайте отде- 
льное ответвление от дерева исходного кода, намеренно внедрите программные 
ошибки и убедитесь, что тесты отловят их. На более высоком уровне можете 
воспользоваться чем-то вроде инструментального средства Сһаоѕ МопКеу от 
компании Ме Их®, чтобы нарушить функционирование служб и проверить ус- 
тойчивость работы своего приложения. Когда вы пишете тесты, примите меры, 
чтобы они вовремя предупреждали об обнаруженных ошибках. 


Тщательное тестирование 


Убедившись в правильности своих тестов и обнаружив ошибки, сделанные 
вами в программе, как вы узнаете, что протестировали свою кодовую базу в 
достаточной степени тщательно? Если кратко — то никак, и вам вряд ли это 
вообще удастся. С этой целью можно было бы воспользоваться инструменталь- 
ными средствами для анализа покрытия тестами, которые наблюдают за при- 
кладным кодом во время его тестирования и отслеживают выполнявшиеся и не 
выполнявшиеся строки кода. Такие инструментальные средства помогают в об- 
щем понять, насколько всеобъемлюще проводимое тестирование, хотя ожидать 
полного покрытия проверяемого кода тестами при этом не стоит”. 

Даже если вам и удастся пройти каждую строку кода, вы все равно не полу- 
чите цельную картину. Ведь реально важно число состояний, в котором может 
находиться программа, но состояния не равнозначны строкам кода. Допустим, 
имеется функция, принимающая два параметра, целочисленные значения кото- 
рых могут находиться в пределах от 0 до 999: 

іп тез (іпё а, іпё р) { 

геіоџгп а / (а + Б); 


8 См. по адресу Пієрѕ: / /пеіғ1іх.одібћир.іо/сһаоѕтопкеу. 


? Любопытное исследование корреляции между покрытием тестами и дефектами в прове- 
ряемом коде см. в Муса! Ипй Тез! Соуетазе [АЮ5518]. 
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Теоретически эта функция, состоящая из трех строк кода, имеет 1 000000 ло- 
гических состояний, 999999 из которых окажутся правильными и лишь одно — 
неправильным, когда а +0 = 0. Простого знания, что данная строка кода была 
выполнена, еще недостаточно, чтобы сделать вывод о выявлении всех возмож- 
ных состояний программы. К сожалению, в общем случае это довольно труд- 
ная задача, иллюстрируемая утверждением — “Солнце превратится в холодную 
твердую глыбу раньше, чем вы решите эту задачу”. 


Проверяйте покрытие тестами состояний, а не исходного кода 


Тестирование на основе свойств 


Чтобы проверить, каким образом в прикладном коде обрабатываются не- 
ожиданные состояния, лучше всего заставить компьютер сгенерировать эти 
состояния. А для того чтобы сформировать тестовые данные по контрактам и 
инвариантам проверяемого кода, можно прибегнуть к тестированию на основе 
свойств. Более подробно этот вопрос рассматривается в разделе “Тема 42. Тес- 
тирование на основе свойств” главы 7 “По ходу кодирования". 


ЗАТЯГИВАНИЕ СЕТКИ 


Наконец, нам хотелось бы поделиться с читателем самым важным принци- 
пом тестирования. Это вполне очевидный принцип, и он поясняется буквально 
в каждой книге на данную тему. Но по какой-то не вполне понятной причине в 
большинстве проектов он по-прежнему не применяется. 

Так, если программная ошибка проникает через сеть существующих тестов, 
для ее перехвата в следующий раз потребуется новый тест. 


Обнаруживайте ошибки единожды 


Как только тестировщик обнаружит программную ошибку, это должен быть 
последний раз, когда он обнаружил данную ошибку. Автоматизированные тесты 
должны быть модифицированы с целью проверять данную ошибку впредь, без 
всяких исключений и независимо от того, насколько она тривиальна и сколько 
раз разработчик будет заверять, что она больше не повторится. 

Все это необходимо сделать, потому что программная ошибка может возник- 
нуть снова. И если у вас, как всегда, нет времени на выявление ошибок, кото- 
рые могли бы вместо вас обнаружить автоматизированные тесты, вам все равно 
придется потратить время на написание нового кода, причем с новыми про- 
граммными ошибками. 
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Полная АВТОМАТИЗАЦИЯ 


Как упоминалось в начале этого раздела, современная разработка опирает- 
ся на сценарные, автоматические процедуры. Пользуетесь ли вы чем-то вроде 
сценариев командного процессора, или просто оболочки с командами гзупс и 
551, или же такими полнофункциональными решениями, как АпѕіЫе, Рирреї, 
СВеЁ или $а[ќ, ни в коем случае не полагайтесь на ручное вмешательство в про- 
цесс тестирования своего кода. 

Однажды мы побывали у своего клиента, где все разработчики пользовались 
одной и той же интегрированной средой разработки. Их системный админист- 
ратор дал каждому разработчику ряд инструкций по установке дополнительных 
пакетов в этой интегрированной среде разработки. Эти инструкции занимали 
много страниц и в основном сводились к тому, чтобы щелкнуть кнопкой мыши 
там, прокрутить содержимое экрана сям, перетащить то, дважды щелкнуть 
кнопкой мыши на этом и повторить все снова. 

Не удивительно, что компьютер каждого разработчика загружался немно- 
го иначе, чем другие. И когда разные разработчики выполняли один и тот же 
прикладной код, в поведении приложения наблюдались незначительные отли- 
чия. Программные ошибки могли возникнуть на одном компьютере, отсутствуя 
при этом на остальных, а отслеживание отличий в версиях любого компонента 
обычно преподносило сюрпризы. 


Не пользуйтесь ручными процедурами 


Дело в том, что люди просто не в состоянии повторять процедуры с такой 
же точностью, как и компьютеры, да этого и нельзя ожидать от них. Сценарий 
оболочки или программа будет всякий раз выполнять одни и те же инструкции 
в неизменном порядке, самостоятельно осуществляя контроль версий. Это дает 
также возможность проверять изменения, происходящие в процедурах сборки 
и выпуска, с течением временем (“но ведь раньше же работало...`). 

Все зависит от автоматизации. Нельзя построить проект на анонимном сер- 
вере в “облаке”, если не автоматизировать этот процесс полностью. И развер- 
нуть программный продукт нельзя автоматически, если этот процесс включает в 
себя стадии, выполняемые вручную. Стоит вам внедрить выполняемые вручную 
стадии хотя бы частично, вы тотчас разобьете очень большое окно!°. Опираясь 
на три столпа контроля версий, строгого тестирования и полной автоматизации, 
ваш проект получит прочное основание, позволяющее вам сосредоточиться на 
самом трудном: доставить удовольствие своим пользователям. 


10 Никогда не забывайте о программной энтропии. Помните о ней всегда. 
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Другие разделы, связанные с данной темой 


Тема 11. Обратимость, глава 2 “Прагматичный подход”. 
Тема 12. Трассирующие пули, глава 2 “Прагматичный подход". 
Тема 17. Игры в скорлупки, глава 3 “Основные инструментальные средства”. 


Тема 19. Контроль версий, глава 3 “Основные инструментальные сред- 
» 
ства”. 


Тема 41. Тестировать, чтобы кодировать, глава 7 “По ходу кодирования”. 
Тема 49. Прагматичные команды. 


Тема 50. Кокосами не обойтись. 


Задачи 


Если сборки, выполняемые вами по ночам или непрерывно, автоматизиро- 
ваны, то почему не автоматизировано развертывание на рабочем сервере? 
В чем особенность этого сервера? 


Можете ли вы протестировать весь свой проект автоматически? Многие 
команды вынуждены признать, что они этого не могут. Почему? Может 
быть, им трудно получить приемлемые результаты? Не мешает ли им это 
убедить спонсоров проекта, что он “готов”? 


Если так трудно протестировать логику приложения независимо от СОТ, 
то что это говорит о самом СИЛІ и связывании? 


ДостАВЛЯЙТЕ УДОВОЛЬСТВИЕ 
СВОИМ ПОЛЬЗОВАТЕЛЯМ 


“Когда вы обвораживаете людей, ваша цель — 
не выманить у них деньги или заставить их 
сделать то, что вам требуется, 

а доставить им огромное удовольствие”. 


Гай Кавасаки! 


Наша цель как разработчиков — доставлять удовольствие своим пользовате- 
лям. Именно для этого мы создаем программные продукты, а не для того, чтобы 
добыть личные данные пользователей, привлечь их внимание или опорожнить 


1 Сиу Камаѕакі — один из самых известных сотрудников компании Арре Сотршег, вне- 
сший в маркетинг компьютера Масіпќоѕћ образца 1984 г. концепцию “евангелизма”, ныне 
повсеместно применяемую в вычислительной технике. — Примеч. пер. 
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их кошельки. Но если оставить в стороне злонамеренные цели, то даже своевре- 
менной поставки работоспособного программного обеспечения окажется явно 
недостаточно. Одно лишь это не доставит удовольствие пользователям. 

Ваших пользователей не особенно вдохновляет написанный вами код. Напро- 
тив, им нужно решать экономические задачи в контексте их собственных целей 
и бюджета. И они верят, что, сотрудничая с вашей командой, сумеют это сделать. 
Они связывают свои ожидания непосредственно с программным обеспечением. 
Они даже не полностью отдают себе отчет в спецификации, которую передают 
вашей команде на рассмотрение, поскольку эта спецификация будет неполной до 
тех пор, пока ваша команда не переработает ее несколько раз подряд. 

Как же тогда выявить ожидания пользователей? Для этого следует задать 
простой вопрос: 


Как знать, будет ли все успешно работать через месяц, год или иной 
срок после завершения проекта? 


Ответ на этот вопрос может вас удивить. Проект, призванный усовершенс- 
твовать рекомендации по применению программного продукта, на самом деле 
можно оценивать с точки зрения сохранения клиентской базы, а проект, при- 
званный соединить две базы данных, — с точки зрения качества данных, а воз- 
можно, и экономии затрат. Но на самом деле значение имеют лишь ожидания 
коммерческой ценности, но не сам программный проект. Ведь программное 
обеспечение служит лишь средством для достижения этих целей. 

И как только удастся прояснить исходные ожидания коммерческой ценности, 
стоящей за проектом, можно приступить к обдумыванию способов получения 
такой ценности, чтобы удовлетворить эти ожидания, выполнив перечисленные 
ниже действия. 


ә Примите меры, чтобы все члены вашей команды ясно понимали эти ожи- 
дания. 


® Принимая решения, подумайте, какой путь быстрее всего удовлетворит 
эти ожидания. 


е Критически проанализируйте требования пользователей в свете их ожида- 
ний. Во многих проектах нам не раз приходилось обнаруживать, что сфор- 
мулированное “требование” на самом деле оказывалось всего лишь пред- 
положением о возможностях конкретной технологии. Это был на самом 
деле любительский план реализации, облаченный в ризы документально 
оформленных требований. Не бойтесь делать предположения, изменяю- 
щие требования, если можете продемонстрировать, что они способны 
приблизить проект к конечной цели. 


® Продолжайте обдумывать эти ожидания, продвигаясь дальше в работе над 
проектом. 
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Как показывает наш опыт, по мере того, как мы лучше узнаем предметную 
область, нам удается точнее делать свои предположения относительно возмож- 
ных путей решения исходных задач в этой области. Мы твердо уверены, что 
разработчики, которым открыты разные особенности функционирования кон- 
кретной организации, нередко способны найти способы связать вместе различ- 
ные части ее деятельности, не всегда очевидные ее отдельным подразделениям. 


Доставляйте пользователям не просто код, а удовольствие 


Если вы хотите доставить удовольствие своему клиенту, установите с ним 
такие отношения, которые позволят вам активно помогать ему решать стоящие 
перед ним задачи. Даже если ваша должность называется “разработчик про- 
граммного обеспечения” или “инженер-программист’, на самом деле она долж- 
на называться “решатель задач”. Ведь программисты-прагматики, по существу, 
занимаются именно тем, что постоянно решают поставленные перед ними за- 
дачи. 


Другие разделы, связанные с данной темой 
® Тема 12. Трассирующие пули, глава 2 “Прагматичный подход". 


® Тема 13. Прототипы и памятные записки, глава 2 “Прагматичный подход”. 


& 


Тема 45. Западня требований, глава 8 “До начала проекта". 


ПМ Арье ираи ЗЛАТА дея ААЛЗ болен А еее АЛЯ ЧАЙ С ето Тех ему ие еее слете дети АИ тет 


ГОРДОСТЬ И ПРЕДУБЕЖДЕНИЕ 


“Вы довольно долго радовали нас”. 


Джейн Остин, Гордость и предубеждение 


Программисты-прагматики не уклоняются от ответственности. Напротив, 
они только рады принять вызов и сделать свой опыт и знания общим достояни- 
ем. Если программисты-прагматики отвечают за проектное решение или фраг- 
мент кода, они выполняют свою работу так, чтобы ею можно было гордиться. 


Подписывайте свою работу 


В прежние времена ремесленники с гордостью подписывали свои работы, 
и вам следует поступать точно так же. Но проектные команды по-прежнему 
состоят из разных людей, и поэтому соблюдение данного правила может до- 
ставить немало хлопот. В некоторых проектах идея владения кодом может за- 
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труднить сотрудничество. Люди могут ревностно охранять свои границы или 
неохотно работать над элементами общего пользования. В итоге проект может 
стать похожим на целый ряд обособленных мелких княжеств. А вы можете быть 
предубеждены относительно своего кода и настроены против своих коллег. 

Но ведь требуется совсем другое. С одной стороны, вам не следует ревностно 
защищать свой код от вторгающихся в него чужаков. А с другой стороны, вы 
должны уважительно относиться к чужому коду. Соблюдение золотого правила 
“Поступайте с людьми так, как вы хотели бы, чтобы они поступали с вами” и 
основание для взаимного уважения среди разработчиков имеют решающее зна- 
чение для того, чтобы следовать приведенному выше совету на практике. 

Анонимность, особенно в крупных проектах, может послужить благоприят- 
ной почвой для развития в команде таких неприятных качеств, как небрежность, 
оплошности, леность, а в конечном счете — некачественный код. И тогда можно 
легко себе внушить, что вы просто мелкая сошка, теша себя слабым оправдани- 
ем, что от вас мало что зависит, вместо того, чтобы писать качественный код. 

И хотя у написанного кода должен быть владелец, он не должен принадле- 
жать кому-то одному. В действительности в своем скромном введении в экстре- 
мальное программирование ? Кент Бек рекомендует общее владение кодом. Хотя 
для защиты от опасностей, кроющихся в анонимности, потребуются дополни- 
тельные нормы практики (например, парное программирование). 

Нам хотелось бы видеть гордость владения кодом, выражаемую словами: 
“Я это написал и отвечаю за свою работу”. Ваша подпись должна стать признан- 
ным знаком качества, а люди должны видеть ваше имя на фрагменте кода, ожи- 
дая, что он написан грамотно, тщательно проверен, подробно задокументирован 
и будет работать надежно. Это должна быть профессиональная работа, написан- 
ная профессионалом — программистом-прагматиком. 

Благодарим вас за внимание. 


2/4 
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ПРИЛОЖЕНИЕ А 


“В долгосрочной перспективе мы формируем свою 
жизнь сами. И этот процесс никогда не кончается 
вплоть до нашей смерти. В конечном счете мы несем 
ответственность за свой выбор. 


Элеонора Рузвельт! 


Когда наша профессиональная деятельность послужила основанием для на- 
писания первого издания данной книги двадцать лет назад, мы участвовали в 
эволюции вычислительной техники от частного любопытства к современному 
императиву всякой деятельности. Спустя двадцать лет, программное обеспече- 
ние выросло за пределы ЭВМ для решения коммерческих задач и по-настояще- 
му овладело всем миром. Но что это действительно значит для нас? 

В своей книге Тйе МуНиса! Мап-Моп!: Еѕѕауѕ оп $ојђмате Епутееттв |Вго96] 
Фред Брукс пишет: “Труд программиста, как и поэта, лишь отчасти не является 
плодом чистого разума. Он строит свои замки в воздухе и из воздуха, создавая 
их усилием своего воображения”. Начиная с чистого листа, мы можем создать 
все, что может нам подсказать наше воображение. И все, что мы создаем, спо- 
собно изменить мир. 

Все технологические новшества (от социальной сети ТиуЩег, позволяющей 
людям планировать революции, процессора в бортовом компьютере, помогаю- 
щем вести автомобиль по скользкой дороге, и вплоть до смартфона) избавляют 
нас от необходимости запоминать мелкие повседневные подробности. Нас всю- 
ду окружают программы, и нас нигде и никогда не покидает воображение. 

Мы, разработчики, находимся в весьма привилегированном положении, пос- 
кольку действительно строим будущее. Это чрезвычайно большая власть, кото- 
рая требует необычайной ответственности. Как часто мы перестаем думать об 
этом? И как часто обсуждаем в своем узком или в более широком кругу, что это 
на самом деле означает? 


' Ееапог Кооземей — американская общественная деятельница, супруга президента США 
Франклина Делано Рузвельта. — Примеч. пер. 
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Во встроенных устройствах применяется на порядок больше компьютеров, 
чем на переносных и настольных компьютерах или в центрах обработки дан- 
ных. Встроенные компьютеры нередко управляют жизненно важными система- 
ми: от электростанций до автомашин и медицинских приборов. И даже простая 
система центрального отопления или бытовая техника может оказаться смер- 
тельно опасной, если она спроектирована или реализована неграмотно. Когда 
вы разрабатываете программы для таких систем и устройств, вы берете на себя 
непомерную ответственность. 

Многие невстроенные системы могут также быть как большим благом, так и 
нанести немалый вред. Так, социальные сети могут способствовать мирной ре- 
волюции или дать повод для отвратительной ненависти. Большие данные могут 
как упростить совершение покупок, так и разрушить всякие остатки конфиден- 
циальности, которые, как вам кажется, у вас еще имеются. Банковские системы 
способны принимать решения о займах, коренным образом меняющие жизнь 
людей. И практически любая система может быть использована для согляда- 
тайства за своими пользователями. 

Мы уже заметили признаки возможного утопического будущего, а также ви- 
дели примеры неумышленных последствий, ведущих к кошмарным антиутопи- 
ям. Отличия этих двух последствий могут оказаться менее заметными, чем вы 
думаете. И это все в ваших руках. 


НРАВСТВЕННЫЙ ОРИЕНТИР 


Ценой, которую приходится платить за столь неожиданно полученную власть, 
является бдительность. Ведь наши действия оказывают непосредственное воз- 
действие на людей. Никто больше не программирует в качестве любителя на 
компьютере с 8-разрядным процессором в гараже, не выполняет в пакетном ре- 
жиме технологический процесс на изолированной от внешнего мира большой 
ЭВМ в центре обработки данных или даже на настольном компьютере. Наше 
программное обеспечение вплетено в саму ткань повседневной современной 
ЖИЗНИ. 

Мы просто обязаны задавать себе два следующих вопроса о каждом фраг- 
менте кода, который выпускаем. 


1. Защитил ли я пользователя? 


2. Воспользовался бы я этим кодом сам? 


Во-первых, следует себя спросить: “Сделал ли я все от меня зависящее, чтобы 
защитить пользователей данного кода от возможного нанесения им вреда? При- 
нял ли я меры к постоянной вставке “заплат” в простую систему слежения за 
ребенком? Обеспечил ли я ручное управление системой центрального отопле- 
ния на случай выхода из строя автоматического термостата? Храню ли я только 
нужные мне данные и шифрую ли любые личные данные?” 
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Никто не идеален, и все время от времени упускают что-нибудь из виду. Но 
если вы не можете честно сказать, что предусмотрели все возможные последс- 
твия и приняли необходимые меры, чтобы защитить от них пользователей, то 
вы понесете определенную ответственность, если дело приобретет скверный 
оборот. 


Прежде всего, не нанесите вред 


Во-вторых, упомянутое выше золотое правило можно было бы переосмыс- 
лить, задав следующие вопросы: “Был бы я рад воспользоваться этим програм- 
мным обеспечением? Хотел бы я поделиться своими подробностями или сде- 
лать мои перемещения достоянием розничных торговых точек? Был бы я рад 
воспользоваться данным автономным транспортным средством и насколько это 
было бы мне удобно?” 

Некоторые изобретательные идеи начинают обходить границы этического 
поведения, и если вы вовлечены в такой проект, то несете такую же ответствен- 
ность, как и его спонсоры. Независимо от того, сколько степеней разделения вы 
могли бы обосновать, остается в силе следующее правило: 


Не потакайте всякой шушере 


ПРЕДСТАВЛЯЙТЕ БУДУЩЕЕ ТАКИМ, КАКИМ ВЫ ХОТИТЕ ЕГО ВИДЕТЬ 


Это ваше дело, ваше воображение, ваши надежды и ваши заботы, дающие 
пищу для размышлений чистого разума на последующие двадцать и больше лет. 
Вы строите будущее для себя и своих потомков, и ваш долг — сделать такое 
будущее, какое все мы хотели бы унаследовать. Признайте это, когда пытаетесь 
делать что-нибудь против такого идеала и имеете смелость противиться ему. 
Представьте будущее таким, каким бы мы могли его иметь, и найдите в себе 
смелость создать его. Стройте воздушные замки каждый день. Ведь у всех у нас 
замечательная жизнь. 


Это ваша жизнь. 
Делитесь ею, празднуйте и стройте ее. 
И ЖЕЛАЕМ ПОЛУЧИТЬ ОТ ЭТОГО УДОВОЛЬСТВИЕ! 
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ПРИЛОЖЕНИЕ В 


Возможные ОТВЕТЫ 
НА УПРАЖНЕНИЯ 


“Я бы предпочел иметь вопросы, на которые 
нельзя найти ответы, чем ответы, 
на которые нельзя поставить вопросы”. 


Ричард Фейнман! 


Ответ на упражнение 1 


Мы думаем, что класс $р112 более ортогональный. Он сосредоточен на 
собственной задаче (разбиении строк), пренебрегая такими подробностями, 
как место поступления строк. Благодаря этому код становится не только лег- 
че разрабатывать, но и повышается его гибкость. Класс 5р1162 можно раз- 
бить на строки, читаемые из файла, сформированного другой подпрограм- 
мой, или же передаваемые через среду. 


Ответ на упражнение 2 


Итак, начнем со следующего утверждения: качественный, ортогональный код 
можно написать практически на любом языке. В то же время у каждого язы- 
ка имеются свои приманки, т.е. средства, способные привести к увеличению 
степени связывания и уменьшению ортогональности. 


В языках ООП такие средства, как множественное наследование, исключения, 
перегрузка операций и переопределение родительских методов (через наследо- 
вание), предоставляют обширные возможности увеличить степень связывания 
не вполне очевидными путями. Определенное связывание возникает и потому, 
что код связывается с данными в самом классе. И как правило, это хорошо 
(когда связывание — благо, мы называем его сцеплением). Но если не сделать 
классы в достаточной степени сосредоточенными на решении конкретных за- 
дач, что это может привести к появлению довольно скверных интерфейсов. 


' Ричард Фейнман — американский физик-теоретик ХХ века. — Примеч. пер. 
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В языках функционального программирования поощряется написание боль- 
шого количества небольших развязанных функций, а также их объединение 
в самых разных сочетаниях для решения конкретной задачи. В теории это 
кажется замечательным, да и на практике все зачастую оказывается именно 
так. Но при этом может все же возникнуть некоторая форма связывания. 
Подобные функции, как правило, преобразуют данные, а это означает, что 
результат выполнения одной функции может стать входными данными дру- 
гой. И если не проявить внимательность, то изменение формата данных в 
одной функции может привести к сбою где-нибудь дальше в потоке преоб- 
разования этих данных. Хорошие системы типов в языках функционального 
программирования отчасти помогают устранять подобные затруднения. 


Ответ на упражнение 3 


Спасение — в простых технологиях! Сделайте несколько эскизов автомоби- 
ля, телефона или дома с маркерами на белой доске. Это совсем не обязатель- 
но должны быть произведения искусства — можно обойтись и контурными 
схематическими рисунками. Затем разместите памятные записки, описыва- 
ющие содержимое целевых страниц, на участках, активизируемых щелчком 
мышью. По ходу совещания можете уточнить рисунки и расположение па- 
мятных записок. 


Ответ на упражнение 4 


Этот язык требуется сделать расширяемым, поэтому он должен приводиться 
в действие с помощью таблицы синтаксического анализатора, каждая ячейка 
которой содержит букву выполняемой команды, признак, указывающий, тре- 
буется ли аргумент, а также имя подпрограммы, вызываемой для выполнения 
данной конкретной команды, как показано ниже. 


1апд/ёог+1е.с 


суреде? зЕгас® { 
сҺаг спа; /* буква выполняемой команды */ 
іпё ПазАга; /* признак, указывающий, требуется ли аргумент */ 
уоіа (*Ғопс) (іпё, іпё); /* вызываемая подпрограмма */ 

} Соттапа; 


зёаёіс Соптапа смаз[] = { 
'Р', АВС, аобе1есфРеп }, 
'0', № АКС, аоРепур }, 
'р', МО АКС, аоРепромп }, 
'№', АВС, аоРепріг }, 
'Е', АВС, аорРепріг }, 
'5', АВС, аорРепріг }, 
"Й", АВС, аоРепріг } 


— — — — — — — 


}; 
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Основная программа довольно проста. Она читает строку, находит команду, 
получает аргумент, если таковой требуется, а затем вызывает функцию обра- 
ботки, как показано ниже. 


1апд/ёог+1е.с 
мһі1е (Ғаесѕ (0џ#Ғ, захеоЕ (РоЕЕ), ѕ+аіп)) { 
Соттпапа *ста = #1іпасоптапа (*БаЕЕ); 


1Е (спа) { 
іпё ага = 0; 


1Е (спа->ВазАга && !деїАгда (раЕЁЕ+1, &ага)) { 
ҒргіпіҒ (ѕёаӢегг, "'%с' пееаѕ ап агадотепё\п", *риЁї#); 
сопёіпие; 


} 


ста->Ғипс (*БаЕЁ, ага); 
} 
} 


Приведенная ниже функция, находящая команду, выполняет линейный по- 
иск в таблице, возвращая совпавшую ячейку или пустое значение МОТГ. 
1апд/ёџг+1е.с 
Соттапа * і пасоттапа (116 ста) { 
106 1; 
Ғог (і = 0; і < АККАҮ 51268 (смаѕ); 1++) { 
1Е (стаѕ[і).ста == ста) 


гебагп спа$ + 1; 


} 


ҒргіпеЁ (ѕёаегг, "Опкпомп соттапа '%с'\п", ста); 
геёсогп 0; 


} 


Наконец, чтение числового аргумента реализуется довольно просто с помо- 
щью функции ѕѕсапї (): 


Іапд/ёџог+1е.с 


іпё сдеіАгд (сопзе сБаг *БоЕЕ, іп *геѕи1+) { 
геёоцгп ѕѕсапҒ (ри##, "5а", геѕи1ії) == 1; 


} 


Ответ на упражнение 5 


Эта задача была фактически решена в предыдущем упражнении, где написан 
интерпретатор внешнего языка. В примерах исходного кода к данной кни- 
ге этот внутренний интерпретатор реализуется с помощью функций типа 
аоХхх. 
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Ответ на упражнение 6 


Используя запись ВМЕ спецификацию формата времени можно было бы оп- 
ределить следующим образом: 


сілте ::= Һоџг атрт | һоцг : мтіпиёе апрт | Һочг : тіпиќе 
атрт ::= ам | рт 

ћоцг = 1де || атат адіс 

піпиѓёе = аідіс 91916 

91916 ::=0111213141516171819 


Чтобы еще лучше определить формат часов и минут, следует учесть, что часы 
могут изменяться в пределах от 00 до 23, а минуты — в пределах от 00 до 59, 
как показано ниже. 


Һоцг со пегепе атое | азат 

піпоіе ::= м-ёепѕ аісіі 

Һ-ёепѕ = 0 [1 

п-іепѕ = 011121314 |5 

аіаії :11= 01112131415 16171819 


Ответ на упражнение 7 


Ниже приведен синтаксический анализатор, написанный на языке Јауасгірі 
с помощью библиотеки Рерјѕ. 


1апд/ред рагзег/ііте рагзег.редјзѕ 


іме 
= Һ:;һоцг оЁЁѕеї:атрт { гефбагп В + оЁЁзѕеї } 
/ В:ВБоцк ":" м:м1поабе оЕЁзее:атрм { гебагп В + м + оЁ#ѕеї } 
/ В:Воцг ":" м:мтіпцёе { гебагр В + м } 

атрт 


= "ам" { геіцгп 0 } 
/ "рт" { гебогп 12*60 } 


ћоцг 
= һҺ:смо Һооџг аідііѕ { гебагп ћ*60 } 
/ һ:аідіё { хебагп һ*60 } 


шлпи се 
= а1:[0-5] а2:[0-9] { гебагп рагзеТпе (а1+а2, 10); } 
4191 
= 4191: [0-9] { гебогп рагзеТп® (а9191%, 10); } 
Кио һоцг 91915 
= а1:[01] 42:[0-9 ] { хебагп рагѕеїлпі (а1+а2, 10); } 
/ а1:[2] 42:[0-3] { геёигп рагѕеїпі (а1+а2, 10); } 


А так выглядит тест, демонстрирующий применение этого синтаксического 
анализатора: 
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1апд/ред_рагзег/фезЕ_Е1те_рагзег. 


Іеї ёеѕі = геаи1ге ('$аре'); 
Іеї ёіте рагѕег = геда1ге('./&1те рагѕег.јѕ'); 


// ёіте ::= Һоцг апрм | 
// һоцг : тіпиёе атрт | 
АА Һоџг : тіпиѓе 
КЎ 
// атрт ::= ам | рт 
А 
// Вопг = адісі | аісдіі 91914 
02 
// тіпоёе ::= 91916 аіаії 
// 
// аіаіё = 0 1112131415161 7181 9 
сопзЕ Һ = (уа1) => уа1*60; 
сопзЕ п = (уа1) => уа1; 
сопзі ам = (уа1) => уа1; 
сопзі рт = (уа1) => уа1 + Һ (12); 
Іеё ќеѕіѕ = { 
"1ат": Һ(1), 


"1рт": рт(һ(1)), 

ЗО р Оу 
"14:30": рм (р (2)) + п(30), 
"2:30рм": рм (В (2)) + м(30), 

} 


еѕі ('Е1те рагз1па', Ғцпсёіоп (і) { 
Ғог (сопзі ѕігіпа іп іеѕіѕ) { 
Іеё геѕиії = ёііте рагѕег.рагѕе ($6г1п9) 
Ё .еаџоа1 (геѕи1іё, ёеѕіѕ [56гіпа], ѕігіпд); 
} 
е.епа () 
}); 


Ответ на упражнение 8 
Ниже приведено одно из возможных решений на языке Кибу. 
1апд/ге рагзег/ііме рагзег.гЬ 


ТІМЕ КЕ = $%ү{ 

(2<919іє> [0-9]) {0} 

(2<Һ ёеп> [0-1]) {0} 

(?2<т кеп>[0-6]) {0} 

(?<атри> ам | рт) {0} 

(?<һоџг> (\9<В ёеп> \4<49191>) | \9<а191%>) {0} 
(?<тіпобе> \а<т ёеп> \<аідіб>) {0} 


\А ( 
( \а<ћоцг> \<атрт> ) 
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| ( \а<Воцг> : \а<и1пиаее> \а<атрт> ) 
| ( \а<поиг> : \ч<илтиее> ) 
уў 


} х 


ЧеЁ рагѕе біте (ѕігіпд) 
геѕиії = ТІМЕ КЕ.тасһ (5% г1п9) 
1Е геѕиіі 
гезитте [= поце вок * 60: 


(гезутЕ[тевисе] || "9". Бот 
(геѕи1є [:атрт) == "рт" ? 12*60 : 0) 
епа 


епа 


В приведенном выше коде применяется специальный прием сначала для оп- 
ределения именованных шаблонов в начале регулярного выражения, а затем 
для обращения к ним как к подшаблонам при фактическом сопоставлении. 


Ответ на упражнение 9 


Наш ответ должен быть основан на нескольких предположениях. 


ә Информация, которую требуется передать, хранится в запоминающем ус- 
тройстве. 


• Нам известна скорость ходьбы человека. 
® Нам известно расстояние между компьютерами. 


• Мы не учитываем время, требующееся для передачи информации как в 
запоминающее устройство, так из него. 


® Издержки на хранение данных приблизительно равны издержкам на от- 
правку данных по линии связи. 


Ответ на упражнение 10 


С учетом допущений, сделанных в предыдущем ответе, на накопителе на маг- 
нитной ленте емкостью 1 Тбайт хранится 8х240, или 2* бит, поэтому данные 
равнозначного объема могут быть переданы по линии связи с пропускной 
способностью 1 Гбит/с приблизительно за 9000 секунд, или около 2,5 часа. 
Если человек ходит с постоянной скоростью 5,6 км/час, то компьютеры долж- 
ны отстоять один от другого на расстоянии почти 14,5 км, чтобы линия связи 
превзошла человека по скорости передачи данных, а иначе он превзойдет ее. 


Ответ на упражнение 14 


Приведем ниже сигнатуры функций на языке ]ауа с пред- и постусловиями 
в комментариях. 


Сначала покажем инвариант для класса: 
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/** 
* @іпуагіапі деебрееа() > 0 
1пр11е$ 1$Е011() // не выполнять, если пусто! 


@1пуаг1апЕ чеёЅрееа () >= 0 && 
деіЅрееа () < 10 // проверить пределы 


ж ж ж + 


< 

Затем пред- и постусловия: 

/ * 
* @рге Маёһ.арѕ (деёѕрееа () - х) <= 1 // изменить только на единицу 
х @рге х >= 0 &&х < 10 // проверить пределы 
* @розЕ деібЅрееа () == // учесть запрашиваемую скорость 
КА 

рчр1іс уоіа ѕеїѕрееа (Ё1па1 іп х) 

/ хх 
* @рге !іѕЕ011 () // не заполнять дважды 
* @розЕ іѕЕџ11 () // удостовериться в выполнении 
БРА 

уоій #і11 () 

/ж% 
* @рге 15ѕЕ011 () // не заполнять дважды 
* @роѕі !іѕЕ0ц11 () // удостовериться в выполнении 
ЫА 

уоіа епріу () 


Ответ на упражнение 15 


В этом ряду 21 число. Если же вы скажете, что их 20, то совершите ошибку, 
подсчитывая промежутки между числами, а не сами числа. 


Ответ на упражнение 16 


• В сентябре 1752 года было только 19 дней”. Это было сделано специально, 
чтобы синхронизировать календари как часть Григорианской реформы. 


® Каталог мог быть удален в другом процессе, у вас могло не быть разреше- 
ния на чтение его содержимого, диск мог быть не смонтирован — в общем, 
картина должна быть вам ясна. 


• Мы специально не указали типы переменных а и Б. Перегрузка операций 
+, = или != могла бы иметь неожиданные последствия. Кроме того, обоз- 
начения а и р могут быть псевдонимами одной и той же переменной, поэ- 
тому при втором присваивании будет перезаписано значение, сохраняемое 
при первом присваивании. А если программа выполняется в параллельном 
режиме и написана неудачно, то значение переменной а может быть об- 
новлено ко времени выполнения операции сложения. 


2 Речь идет о переходе на Григорианский календарь Великобритании. В разных странах этот 
переход (с появлением укороченных месяцев) происходил в разные годы. — Примеч. ред. 
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® В неевклидовой геометрии сумма углов треугольника не будет равна 180°. 
Представьте треугольник, начерченный на поверхности сферы. 


® Високосные минуты могут насчитывать 61 или 62 секунды. 


е В зависимости от конкретного языка числовое переполнение может оста- 
вить результат операции а+1 отрицательным. 


Ответ на упражнение 17 


В большинстве реализаций С и С++ никак не проверяется, ссылается ли фак- 
тически указатель на действительную область памяти. Типичная ошибка со- 
стоит в том, что блок памяти освобождается вместе со ссылкой на него далее 
в программе. Но к тому времени область памяти, на которую делается ссылка 
по указателю, может быть вполне выделена уже для других целей. Устанав- 
ливая пустое значение МОТГ в указателе, программисты надеются предотвра- 
тить эти ошибки. 


Ответ на упражнение 18 


Устанавливая значение ссылки МОТГ, вы тем самым сокращаете на единицу 
количество указателей на ссылаемый объект. И как только это количество 
достигнет нуля, объект может стать пригодным для сборки мусора. Установ- 
ка значения ссылок равным МОТІ может иметь существенное значение для 
долго выполняющихся программ, где программисты должны гарантировать, 
что объем используемой памяти со временем не увеличится. 


Ответ на упражнение 19 


Простая реализация данного компонента может выглядеть следующим об- 
разом: 


еуепіё/зёгіпдз ех 1.гр 


сіаѕѕ ЕЅМ 
АеЁ іпіііа1іге (ігапѕіііопѕ, іпіёіа1 ѕбабе) 
@ёсапѕіїіопѕ = ёгапѕіііопѕ 
@ѕёабсе = іпіїіа] зіаѓіе 
епа 
де# ассері (еуепїі) 
@ѕёаѓе, асііоп = ТКАМЗТТТОМ$ [@ѕбаѓе] [еуепї] 
|| ТКАМЅІТІОМ№5 [@5іаіѓе] [:аеҒаџ1+] 
епа 
епа 


Ответ на упражнение 20 


• ...получены три события о выходе из строя сетевого интерфейса в течение 
пяти минут. 
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Такое поведение можно было бы реализовать с помощью конечного авто- 
мата, но сделать это было бы труднее, чем кажется на первый взгляд. Ведь 
если получить события в 1-ю, 4-ю, 7-ю и 8-ю минуты, то придется выдать 
предупреждение на четвертом событии. Это означает, что конечному авто- 
мату придется сбросить себя в исходное состояние. 


По этой причине избранной технологией, по-видимому, могут оказаться 
потоки событий. У этих потоков имеется реактивная функция Ба ЕЕег (), 
принимающая параметры $12е и оЕЁзе® и возвращающая каждую груп- 
пу из трех входящих событий. И тогда можно проанализировать отметки 
времени наступления первого и последнего события в группе, чтобы выяс- 
нить, следует ли выдавать предупреждение. 


е ...после захода солнца обнаруживается движение сначала внизу, а затем 
вверху лестницы, включить лестничное освещение. 


Этот режим, вероятно, можно было бы реализовать, используя определенное 
сочетание шаблона “Издатель-подписчик” и конечных автоматов. Так, ис- 
пользуя шаблон “Издатель-подписчик’, можно было бы сначала распростра- 
нить события среди любого количества конечных автоматов, а затем дать 
конечным автоматам возможность определить, что именно следует делать. 


® ...уведомить различные системы учета о выполнении заказа. 


Этот режим лучше всего было бы реализовать, используя шаблон “Изда- 
тель-подписчик”. И хотя для этой цели можно было бы воспользоваться 
потоками событий, но тогда и уведомляемые системы учета пришлось бы 
проектировать на основе потоков. 


• ...отправить соответствующие запросы трем серверным службам, ожидая 
от них ответов. 


Это похоже на рассмотренный пример, в котором потоки используются для 
выборки пользовательских данных. 
Ответ на упражнение 21 
1. Налоги на поставку и с продаж вводятся в заказ: 
основной заказ -» окончательный заказ 


В обычном коде, вероятнее всего, должна быть определена одна функция 
для расчета затрат на поставку, а другая — для расчета налога. Но если 
принять во внимание выполняемые здесь преобразования, то заказ просто 
с перечисленными в нем товарами можно преобразовать в новый вид за- 
каза на поставку. 


2. Приложение загружает конфигурацию из именованного файла: 


имя файла — структура конфигурации 
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3. Пользователь входит в веб-приложение, регистрируясь в нем: 


учетные данные пользователя Э сеанс работы 


Ответ на упражнение 22 
Исходное высокоуровневое преобразование 


Ғіе1а сопеепеёз аз ѕігіпд 
— [уа11Аафе & сопуег®] 
— {:ок, уаіце)} | {:егког, геаѕоп} 


можно разделить следующим образом: 


Е1е1а сопёепіз аз ѕігіпа 
ә [сопуегі ѕігіпд ёо іпёеаег)] 
ә [сһеск уха]1ае >= 18] 
— [сһеск уха]1ае <= 150] 
— {:оКк, Уа1ае} | {:екггог, геаѕоп} 


При этом предполагается наличие конвейера для обработки ошибок. 
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Ответим сначала на вторую часть данного упражнения: мы предпочитаем 
первый фрагмент кода. 


Во втором фрагменте кода на каждом шаге возвращается объект, реализу- 
ющий следующий вызов метода. В частности, объект, возвращаемый мето- 
дом сопеепЕ оЁ(), должен реализовать метод Ғіпа таёсһіпо 1іпеѕ () 
И Т.Д. 


Это означает, что объект, возвращаемый методом сопіёепі ої (), привязан 
к нашему коду. Представьте, что требование изменилось, и тогда нам придет- 
ся пренебречь строками, начинающимися со знака #. В стиле преобразова- 
ний это нетрудно выразить следующим образом: 


сопз@ сопіепі = Е11е.геаа (Ғі1іе папе); 

сопзЕ по сопмепе$ = гепоуе соммепф$ (сопіепі) 

сопзі 1іпеѕ Ғіпа таєсһіла 11іпеѕ (по соптепіѕ, раїѓегп) 
сопзі геѕиії Егопсабе 1іпеѕ (1іпеѕ) 


Этот код будет работать, даже если поменять порядок вызова методов 
гепоуе соптепіѕ () и Ғіпа таёсһіпао 1Ііпеѕ (), хотя сделать это в стиле 
составления методов в цепочку будет труднее. А где должен находиться метод 
гетоуе соттепізѕ (): в объекте, возвращаемом методом сопіепі оЁ\(), 
или же в объекте, возвращаемом методом Ғіпа таїсһіпо 1іпеѕ ()? И на- 
рушится ли работа какого-нибудь другого кода, если изменить такой объект? 
Вследствие именно такого связывания стиль составления методов иногда еще 
называют крушением поездов. 
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» Обработка изображений. Для простого планирования рабочей нагрузки 
на параллельные процессы может лучше всего подойти общая рабочая 
очередь. А если требуется учитывать ответную реакцию, т.е. воздействие 
результатов обработки одного участка изображения на другие его участки, 
как, например, в приложениях машинного зрения или сложных трехмер- 
ных преобразованиях, искажающих изображение, то можно рассмотреть 
возможность применения системы типа классной доски. 


ө Групповое ведение календаря. Система типа классной доски может быть 
в данном случае вполне пригодным вариантом. Она позволит оповещать 
на классной доске о планируемых совещаниях и сделать ее доступной для 
всех заинтересованных лиц. Отдельные подразделения могут функциони- 
ровать автономно, но при этом важна их реакция на принимаемые реше- 
ния, а участники проекта могут приходить и уходить. 


Можно также рассмотреть возможность разделения такого рода системы 
типа классной доски на отдельные категории в зависимости от того, кто 
осуществляет в ней поиск. Так, младший персонал может интересовать 
только то, что происходит непосредственно в их учреждении, отдел кад- 
ров — англоязычные подразделения по всему миру, а высшее руковод- 
ство — все в целом. 


Допускается также определенная гибкость в отношении форматов данных, 
позволяющая не обращать внимание на непонятные форматы или языки. 
Понимание разных форматов данных требуется только в тех подразделе- 
ниях, которые принимают участие в совместных совещаниях, хотя их учас- 
тникам совсем не обязательно знать все возможные форматы. Благодаря 
этому связывание сокращается до нужной степени, не налагая никаких ис- 
кусственных ограничений. 


® Инструментальное средство текущего контроля сети. Это очень похоже 
на прикладную программу, принимающую и обрабатывающую заявки на 
залог или заем (см. раздел “Классная доска в действии” главы 6 “Парал- 
лельность”). В данном случае от пользователей поступают сообщения о 
неполадках в сети и автоматически составляются статистические отче- 
ты — и все это размещается на классной доске. Одушевленный или неоду- 
шевленный (программный) посредник может анализировать содержимое 
классной доски, чтобы диагностировать сетевые сбои. Так, две ошибки в 
линии связи могут быть вызваны всего лишь воздействием космических 
лучей, но 20 тысяч ошибок явно означают неисправность сетевого обору- 
дования. Подобно тому, как сыщики раскрывают тайну убийства совмест- 
ными усилиями, работу нескольких подразделений можно организовать 
таким образом, чтобы они анализировали и предлагали варианты устра- 
нения неполадок в сети. 
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Когда речь идет о списке, состоящем из пар “ключ-значение’, обычно счита- 
ется, что ключи в нем уникальны. И библиотеки хеширования обычно соб- 
людают это правило, обеспечивая надлежащее поведение самого хеш-кода 
или выдавая сообщения об ошибках дублирования ключей. Но на массив 
такие ограничения, как правило, не накладываются, поэтому в нем могут 
благополучно храниться дублирующиеся ключи, если только в прикладном 
коде против этого не приняты специальные меры. Так, в данном случае одер- 
живает верх первая же запись, найденная по совпадению с заданным ключом 
Рероз1{Ассочпь, тогда как все остальные записи игнорируются. При этом 
порядок следования записей не гарантируется, поэтому в одних случаях та- 
кая структура данных оказывается пригодной, а в других — непригодной. 
А что касается компьютеров, не задействованных на стадии разработки и 
эксплуатации, то речь может идти только о простом совпадении. 
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Тот факт, что исключительно числовое поле вполне пригодно для хранения 
телефонных номеров в США, Канаде и на Карибских островах, является 
простым совпадением. По спецификации ГТО формат международного те- 
лефонного звонка начинается со знака +. В некоторых местных телефонных 
сетях употребляется также знак *, и зачастую номер телефона может содер- 
жать начальные нули. Поэтому номера телефонов ни в коем случае нельзя 
хранить в числовом поле. 
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Все зависит от того, где именно вы находитесь. Так, в США единицы изме- 
рения объема основываются на галлоне, обозначающем объем цилиндра вы- 
сотой 6 дюймов и диаметром 7 дюймов, округленный до ближайшего куби- 
ческого дюйма. А в Канаде “одна чашка” в рецепте может обозначать одну из 
следующих мер объема: 


® 1/5 британской кварты, или 227 мл 


1/4 американской кварты, или 236 мл 
е 26 метрических столовых ложек, или 240 мл 


• 1/4 литра, или 250 мл 


Если только речь не идет о рисоварке, где “одна чашка” обозначает объем 
180 мл. Эта мера объема происходит от японской единицы измерения коку, 
устанавливающей объем сухого риса, требующегося одному человеку на один 
год, т.е. около 180 л. Чашки для рисоварки имеют объем 1 го, т.е. 1/1000 коку, 
а следовательно, они обозначают количество риса, которое человек обычно 


съедает за один присест”. 


| Благодарим за разъяснение всех этих мер риса Эви Брайянта (Аз! Вгуапё; ёауіргуап+). 
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Очевидно, что на это упражнение нельзя дать какой-то однозначный ответ. 
Но в то же время можно дать пару указаний, в каком направлении следует 
двигаться в поисках ответа. 


Если вы обнаружите, что полученные вами результаты не укладываются на 
плавную кривую, в таком случае, возможно, придется проверить, не исполь- 
зуются ли вычислительные мощности процессора вашего компьютера для ка- 
кого-нибудь другого вида деятельности. Вряд ли вы получите хорошие циф- 
ры, если фоновые процессы периодически отнимают процессорное время у 
ваших программ. Возможно, стоит также проверить, как используется опера- 
тивная память. Стоит, например, приложению начать пользоваться областью 
подкачки, как производительность резко упадет. 


Ниже приведен график результатов выполнения кода на одном из наших 
компьютеров. 


16000 Время сортировки одномерного массива 
целых чисел разными алгоритмами 
ә 
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Размер входных данных ( 1000, 100 000 для быстрой сортировки) 
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Это можно сделать двумя способами. Один из них состоит в том, чтобы об- 
думать задачу в уме. Так, если в массиве содержится лишь один элемент, то 
для его перебора цикл не требуется. На каждом дополнительном шаге цик- 
ла размер массива, в котором осуществляется поиск, удваивается. Следова- 
тельно, общая формула для определения размера массива такова: и = 2”, где 
т — количество шагов цикла. Если же применить логарифм по основанию 2 
к каждой стороне формулы, по получим 12п = 12”, и, по определению лога- 
рифма, |2 п = т. 
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Чтобы ответить на данное упражнение, придется вспомнить школьный курс 
математики и, в частности, следующую формулу преобразования логарифма 
по основанию а в логарифм по основанию Ё: 


где Іор № — константа, которой можно пренебречь в асимптотическом выра- 
жении результата. 


Ответ на упражнение 31 


В качестве тестируемого свойства можно проверить успешное выполнение 
заказа, если на складе имеются достаточные запасы товаров. Заказы можно 
сначала составить для произвольных количеств товаров, а затем проверить, 
возвращается ли кортеж с признаком "ОК", если на складе имеются доста- 
точные запасы заказываемых товаров. 


Ответ на упражнение 32 


Это удобный случай для тестирования на основе свойств. Модульные тесты 
можно сосредоточить на отдельных случаях, когда результат получен дру- 
гими средствами, а в тестах на основе свойств уделить основное внимание 
решению следующих вопросов. 


е Перекрываются ли два любых ящика? 


® Выступает ли какая-нибудь часть любого ящика за пределы кузова грузо- 
вика по ширине или по высоте? 


е Меньше или равна 1 плотность упаковки, т.е. площадь, занимаемая ящи- 
ками и деленная на площадь кузова грузовика? 


® Если это часть требования, то превышает ли плотность упаковки мини- 
мально допустимую плотность? 
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Ответ на упражнение 33 


]. 


Данное требование сформулировано как подлинное. В частности, среда 
приложения может накладывать на него свои ограничения. 


‚ Само по себе данное требование не сформулировано как таковое. Но для 


того чтобы выяснить, что действительно требуется, придется задать вол- 
шебный вопрос: “Зачем?” 


Возможно, это корпоративная норма, и тогда конкретное требование долж- 
но быть сформулировано, например, следующим образом: “Все элементы 
пользовательского интерфейса должны соответствовать принятым нормам 
МераСогр Оѕег Іпїегѓасе Ѕїапаагіѕ У 12.76”. 


А возможно, данный цвет просто понравился команде, оформляющей 
пользовательский интерфейс. В таком случае следует подумать, каким об- 
разом эта команда меняет свое мнение, и сформулировать данное требо- 
вание, например, таким образом: “Цвет фона всех модальных окон должен 
быть настраиваемым, а в первоначальной поставке — серым”. А еще лучше 
сформулировать более обширное требование: “Все визуальные элементы 
приложения (цвета, шрифты и языки) должны быть настраиваемыми”. 


Наконец, данное требование может просто означать, что пользователю тре- 
буется различать модальные и немодальные окна. В таком случае данное 
требование может потребовать дополнительного обсуждения. 


Это требование сформулировано не как таковое, а как архитектурное 
решение. Сталкиваясь с чем-то подобным, необходимо уточнить мнение 
пользователя по данному вопросу. В чем здесь дело: в масштабировании, 
производительности, стоимости или безопасности? Ответы на эти вопро- 
сы помогут принять более обоснованное проектное решение. 


Исходное требование, вероятно, ближе к следующему: “Система должна 
не давать пользователю ввести недостоверные данные в отдельных полях 
и предупреждать его при всякой попытке это сделать’. 


. Это требование вряд ли можно считать сформулированным как таковое, 


исходя из некоторых аппаратных ограничений. 


И, наконец, ниже приведено решение задачи проведения трех прямых ли- 
ний через четыре точки, не отрывая ручку от листа бумаги и возвращаясь 
в исходную точку. 


Здесь цифрами показано, З 
как соединить четыре точки 
тремя линиями, не отрывая 

ручку от листа бумаги и 


возвращаясь в исходную точку 2 
1 Е. Ч 
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и связывание, 200 
множественное, 202 


о 


Обратимость, 80 
Общение, 50 
в Интернете, 56 
в команде, 324 
диалог, 53 
документация как форма общения, 54 
на родном языке, 50 
обратная связь, 51 
особенности и формы, 50 
свободное, 324 
стиль, 52 
удобный момент, 52 
Объект, 21 
Ортогональность, 69 
и тестирование, 76 
поддержание, 75 
преимущества, 71 
при документировании, 76 
при проектировании, 73 
Осведомленность об окружающей 
обстановке, 39 
Ответственность 
взятие на себя, 32 
определение, 32 
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Отладка, 125 
бинарный поиск ошибки, 128; 129 
вопросы психологии, 125 
воспроизведение ошибок, 127 
и тестирование, 127 
контрольный список, 134 
метод резинового утенка, 131 
мысленная установка на выполнение, 126 
наблюдения, 126 
проверка предположений, 133 
протоколирование и трассировка, 130 
стратегии, 127 
утечка ресурсов, 131 

Оценка, 100; 101 
графика работ, 104 
проектов РЕКТ, 104 
точность, 100 
шкала временных оценок, 101 


П 


Параллелизм, 213; 216; 217 
Параллельность, 213; 216 
пассивная, 235 
средства поддержки, 226 
Перемены, 30 
Повторное использование, 69 
Полиморфизм, 200 
Поток 
данных, 183; 194 
событий, 185 
Прагматичность 
знание меры, 42 
основы мышления, 30 
Преждевременная оптимизация, 258 
Принцип 
единообразия доступа, 67 
легкости изменения, 58 
наименьших привилегий, 286 
не навреди, 345 
не повторяться, 16; 60; 61; 62 
ортогональности, 69; 77 
поедания слона кусочками, 105; 164; 268 
указывай, а не спрашивай, 171 
Программирование 
гибкость, 315 
групповое, 311; 313 
именование, 291 
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метод трассирующих пуль, 84 
в команде, 325 
недостатки, 87 
преимущества, 86 
налог на наследование, 167 
на основе тестирования, 267 
обдуманное, 250 
парное, 311; 312 
по совпадению, 145; 239; 246 
преобразовательное, 186 
прототипирование, 88; 89 
профилирование, 257 
развязывание, 167; 169 
реактивное, 183 
решение сложных задач, 310 
связывание, 167 
утвердительное, 152 
Программист 
особенности профессии, 23 
прагматик 
автоматизация, 325 
анонимность, 341 
взлом сознания, 243 


взятие на себя ответственности, 32 


знания, 43 

индивидуальные навыки, 26 
инстинкт, 243 

критическое осмысление, 240 


манипулирование текстом, 134 
начальный набор инструментов, 331 


обратная связь, 301 
обучение, 47 

общение, 50 

общие характеристики, 24 
озарение, 243 
определение, 23 
ответственность, 340 
отладка, 125 


отличительные особенности, 29 


оценка, 100 
подозрительность, 284 
пополнение знаний, 47 
синдром самозванца, 242 
становление, 25 
удовольствие клиента, 340 
чужой код, 244 
этика, 344 

свобода выбора, 31 


Программное обеспечение 
деградация, 34 
факторы, 34 
достаточно хорошее, 40 
качество, 41 
раздутость функциональности, 43 
требования, 298 
Проектирование, 58; 72 
нисходящее, 189 
ортогональных систем, 73 
по контракту, 141 
реализация, 145 
сверху вниз, 269 
снизу вверх, 269 
Проектный шаблон 
декоратор, 74 
издатель-подписчик, 182 
недостатки, 182 
обозреватель, 181 
недостатки, 182 
синглтон, 75 
стратегия, 75 
Протокол, 203 
Прототип, 91; 244 
Прототипирование, 88; 89; 90 
архитектуры, 91 
и метод трассирующих пуль, 88 
предостережения, 92 
Профайлер, 257 
Процесс, 227 


Р 


Разработка 
гибкая, 315; 316 
на основе тестирования (ТОО), 144; 267 
Ресурс 
балансировка, 158 
взаимоблокировка, 159 
вложенное выделение, 159 
выделение и освобождение, 156 
инкапсуляция, 159 
исчерпание, 43 
Рефакторинг, 62; 76; 260 
автоматический, 264 
причины, 261 
рекомендации, 263 
Риск, 45 


С 


Связывание, 168 
временное, 214 
глобальные данные, 173 
конвейеры, 173 
признаки, 169 
транзитивность, 169 
цепочки вызовов, 170 
через наследование, 200 
Семафор, 221 
блокировка и освобождение, 222 
реализация, 221 
Сигнатура, 189 
Событие, 176; 183 
Совет, 25; 30; 33; 35; 38; 39; 41; 45; 48; 50; 
53; 54; 58; 61; 69; 71; 81; 82; 84; 90; 94; 
105; 109; 114; 116; 121; 125; 126; 128; 
132; 133; 135; 139; 143; 151; 152; 156; 
159; 164; 166; 169; 171; 172; 174; 175; 
100; 188; 193; 202; 204; 205; 207; 208; 
215; 219; 225; 228; 236; 243; 249; 256; 
257; 262; 265; 266; 270; 273; 274; 276; 
286; 288; 295; 298; 299; 300; 302; 306; 
308; 314; 315; 320; 323; 325; 328; 330; 
332; 333; 335; 336; 337; 340; 345 
Состояние, 144 
общее, 214; 220 


Т 


Текст, 134 
простой, 109 
редактор, 116 
навыки, 116 
удобочитаемость, 109; 111 
формат, 110 
хранение информации, 109 
языки, 135 
Теория разбитых окон, 35 
и программирование, 35 
Тестирование, 76; 127; 265; 266; 333 
автоматизация, 337 
анализ покрытия, 335 
интеграционное, 334 
и связывание, 266 
культура, 274 
модульное, 144; 271; 333 
на основе свойств, 276; 281; 336 
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под предельной нагрузкой, 334 
производительности, 334 
регрессионное, 282 
соответствия контракту, 271 
специальное, 273 
тестов, 335 
Технический дневник, 137 
Трассирующие пули, 83 


У 


Утверждение, 145; 152 
аѕѕегі, 152 
и побочные эффекты, 153 
отключение, 154 
применение, 153 


Э 
Энтропия, 34 
Я 
Язык 
Сиситьег, 94 
5ОМ, 98 
ОМІ, 215 
ҮАМІ, 96 


манипулирования текстом, 135 
предметно-ориентированный, 94; 97 

внешний, 97 

внутренний, 97 
программирования 

С++, 78; 146; 160; 200; 202 

Сюодлиге, 97; 142; 191 

ЕЩЕ], 144; 145 

Ейхи, 97; 143; 194 

Ет, 191 

ЕПапр, 232 

Е#, 191; 194 

НаѕКе]!, 191; 194 

Јаха, 200 

]ауазсирь 191 

Руіоп, 135 

Кобу, 135 

Киѕі, 160 

Зсаа, 194 

Зи а 67, 199 

ЗтаШа[К, 200 

ЗУЫ, 191 

назначение и особенности, 93 

поддержка параллельности, 226 
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РЕФАКТОРИНГ КОДА 


НА ЈАМАЅСКІРТ 
ВТОРОЕ ИЗДАНИЕ 


Мартин Фаулер 


“Любой в состоянии написать код, который будет 
понятен компилятору. Хороший программист пишет 
код, который будет понятен человеку”. 

М, Фаулер, 1999 г. 


РЕФАКТОРИНГ _ 
КОДА НА ЈАУАЅСКІРТ 


МАРТИН ФАУЛЕР 
ПРИ УЧАСТИИ 


КЕНТА БЕКА 


ВТОРОЕ ИЗДАНИЕ 


мумии ми Шатзри 5 тд.соп 


|5ВМ 978-5-907144-59-0 


Рефакторинг уже давно и прочно 
занимает свое достойное место 
среди технологий 
программирования, и не 

в последнюю очередь благодаря 
Мартину Фаулеру — автору одной 
из тех книг, которые написаны “на 
все времена”. 

Сам принцип рефакторинга прост: 
это последовательность 
небольших шагов, таких как 
перемещение поля из одного 
класса в другой, вынесение 
фрагмента кода из метода и его 
превращение в самостоятельный 
метод или даже перемещение кода 
по иерархии классов. 
Кумулятивный эффект таких 
малых изменений состоит 

в существенном улучшении 
архитектуры существующего кода. 
Новое издание классической 
книги достойно того, чтобы занять 
свое место на книжной полке 
каждого серьезного 

программиста — вне зависимости 
от используемого языка 
программирования. 


в продаже 


“9/0 одна из самых важных книг в моей жизни.” 
ОБИ ФЕРНАНДЕС, автор книги Ге Ка ТР) 


“В этом издании вы найдете немало практических советов как технического, так 
и профессионального характера, которые еще многие, годы сослужа вам верную служду 


в ваших проектах. ' 
АНДРЕА ГУЛЕ, гсисральный дпректор компании СогоЪус$; 


учредитель компании ТееасуСо4е.Воск$ 


“Молния иногда поражает дважды, чему эта книга служит явным доказательством.” 
ВМ (ВИКИ) БРАССЕР, лирсктор программы Ореп $оитсе Хітабсоу 


в компании Јитрег МебуотКѕ 


Настоящее издание относится к числу тех редких образцов технической литературы, которые стоит 
читать, перечитывать п снова читать в течение многих лет. [13 него читатель, будь он начинающим или 
опытным разработчиком программного обеспечения, сможет всегда почерпнуть свежие пдеп. 

Дэвид Томас и Эндрю Хант написали первое издание этой замечательной книги в 1999 году, чтобы 
помочь своим клиентам в создании более качественного программного обеспечения и помочь открыть 
для себя удовольствие от программирования. Уроки, извлеченные из этой книги, помогли целому 
поколению программистов усвоить саму суть разработки программного обеспечения, независимо 

от конкретного языка, ополпотеки пли методики. Предложенный авторами книги прагматичный 
философский подход к разработке программного обеспечения нашел широкое распространение, 
породив сотни других книг и статей, а также послужил началом для тысяч успешных карьер и историй 
професспонального роста. 

Теперь, двадцать лет спустя, в новом издании авторы по-новому взглянули на то, что такое 
современный программист. В этом издании затрагиваются самые разные темы: от личной 
ответственности разработчика до развития его карьеры, архитектурные приемы, обеспечивающие 
гиокость исходного кода п возможность легкого его изменения. Прочитав эту книгу, вы узнаете как: 


* оороться с деградацией программного ооеспечения “ решать задачи, лежащие в основе параллельного 


* постоянно учиться программирования 

" избегать \овушек, кроющихся в дуб \провании * организовывать команды программистов- 
знаний прагматиков 

= писать гиокий, динамический и адаптируемый код а Орал ь на себя ответственность за свою работу 

* овладевать основными инструментальными и карьеру 
средствами " строго и эффективно тестировать 

" избегать программирования по совпадению " реализовывать начальный набор 

= изучать подлинные требования инструментальных средств программиста- 


* защищаться от уязвимостей в системе безопасности прагматика 


= Оставлять ҮДОВО \ьствпе своим пользователям 


Эта книга написана в виде последовательного ряда автономных тем-разделов, с, \обрена немалой долей 
классических и свежих анекдотов, тщательно проду манными примервин пин гересными аналогиями.. 

В ней показаны наи. \учише подходы к разр: оотке прогр: \іММНОГО обеспечения п основные ловушки на 

ЭТОМ пу ги. | [ачин: 1юпше пли опытные про аммисты, как п ру ководители прот іІММНЫХ проектов, смогут 
извлечь немало уроков из этой книги в своей повсе дневной деятельности, оыс е добившись улу чшений 

В производительнос ГИ труда, пунктуальности и удовле гвореннос’ ги своей работой. Книга поможет читателю 
выработать И развить навыки и отношения, образующие прочный фундамент его успешной карьеры 

В долгосрочной перспективе. В конечном счете он станет программистом-прагматиком. 
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